From owner-ibis  Wed Dec  1 10:57:26 1999
Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA13769; Wed, 1 Dec 1999 10:57:26 -0800 (PST)
Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id KAA22093; Wed, 1 Dec 1999 10:56:18 -0800 (PST)
Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R)
	id KAA21681; Wed, 1 Dec 1999 10:56:14 -0800 (PST)
Sender: bob_ross@mentorg.com
Message-ID: <38456F4E.596D9795@mentor.com>
Date: Wed, 01 Dec 1999 10:56:14 -0800
From: Bob Ross <bob_ross@mentorg.com>
X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: ibis@eda.org, ibis-users@eda.org
Subject: IBIS REFLECTOR VIRUS ALERT
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

To All:

If you receive a message shown below, DO NOT OPEN the attached
zipped_files.exe file:

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

Hi <your name> !
I received your email and I shall send you a reply ASAP.
Till then, take a look at the attached zipped docs.
bye.
 <<zipped_files.exe>>    

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


Many Corporations are already dealing with a new variant of the
autospam TROJ_EXPLOREZIP worm: TROJ_EXPZIPWMPAK.

Some machines on the IBIS reflector e-mail lists may have
already been infected.  

When you send any e-mail through the IBIS reflectors or directly,
you may get the above response sent directly back to you.  DO NOT
OPEN the attached zipped_files.exe file.  Below is part of an
explaination sent out on my site:

> After a user clicks on the attachment, this destructive trojan 
> searches hard drives C: through Z:, selecting the Microsoft Word, 
> Excel and PowerPoint files as well as source code files used by
> programmers including  C++, C, and Assembler source files and 
> reduces their file size to zero, making the data unrecoverable.  
> When executed, TROJ_EXPZIPWMPAK utilizes MAPI enabled email 
> systems, to automatically reply to any subsequently received 
> email messages.  The email reply will include the infected 
> attachment with the message shown above.  It will use the 
> subject line of the received email when it replies.
> 
> "TROJ_EXPLOREZIP caused millions of dollars of damage worldwide 
> the first time since it overwrites files, instead of just deleting
> them, it's particularly damaging.


Bob Ross
Mentor Graphics
From owner-ibis  Thu Dec  2 13:35:28 1999
Received: from oliver.al.dynip.com (al@209-63-189-109.sea.jps.net [209.63.189.109]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA23250 for <ibis@vhdl.org>; Thu, 2 Dec 1999 13:35:23 -0800 (PST)
Received: from localhost (localhost [[UNIX: localhost]])
	by oliver.al.dynip.com (8.9.3/8.8.7) id NAA08064
	for ibis@vhdl.org; Thu, 2 Dec 1999 13:30:33 -0800
From: Al Davis <aldavis@ieee.org>
Reply-To: albertd@hyperlynx.com
To: Ted "'ibis@vhdl.org'" <ibis@vhdl.org>
Subject: Re: Future directions for IBIS
Date: Thu, 2 Dec 1999 13:03:44 -0800
X-Mailer: KMail [version 1.0.20]
Content-Type: text/plain
References: <3839903F.CB7632F2@mentor.com>
MIME-Version: 1.0
Message-Id: <99120213303306.01159@oliver.al.dynip.com>
Content-Transfer-Encoding: 8bit

Try this:

(embellishing on the seed note by Stephen Peters)

The IBIS model is not truly behavioral, but a parameter
list for pre-defined structures.

Model ...
  input, output, i/o, open drain, etc.
Augmentations to the model ...
  driver schedule, bus hold, dynamic clamp ...
Containers ...
  component. package model, ebd, connector

We have all suffered through the need for yet another
structure to be added to the spec, or the discovery that
something is missing,  unclear, or difficult to implement.


My proposal is to have essentially two sections, a
parameter section functionally similar to the existing
IBIS, and a structure definition section that defines these
structures.  By doing this, this structure definition is
removed from the committee and simulator designer, and made
available to the model developer.  A netlist like language
could be used to define them.

To provide a migration path, and prove the appropriateness
of the new language, a set of structure definitions could
be provided with any conforming IBIS simulator, in the same
sense that any C compiler provides a standard library. 
These would be provided in source form so they could be
used by model developers as a prototype for developing
their new structures.  I have these for some of the ibis
model types.  So far, I was able to define structures that
can be expanded by an existing IBIS [Model] section, for
100% backward compatibility.

As an added benefit, we could provide these structure
definitions for 1.0, 1.1, 2.0, 2.1, 3.0, 3.1, 3.2 ...... 
with little additional effort.  All of the proposed BIRDs
can be added to the structure with trivial effort.

This structure should be netlist style, and can be inspired
by the Spice style.  As an alternate to providing a value
for any component, a parameter name could be specified. 
The values for the parameter would be provided in the
parameter section, which would look much like  the existing
IBIS format.  Parameters could be scalars, tables,
multi-dimensional tables, or equations.  They may or may
not have ranges, depending on the application.

Since this will be processed, the format does not need to
conform to any particular Spice implementation.  It can
provide component types and parameters that do not exist in
standard Spice.  It is not much work for a simulator
developer to add the necessary functionality to Spice.  It
also should be not much work to generalize the simpler
interconnect simulators to take these components.

Some elements to provide ...

The classic R, L, C, V, I, E, G .. both in the simple form,
with a value, and an advanced form where the value is a
parameter, for example ...

Rpu  (A1  A2)   I=pullup[V]

This says that the v/i characteristic of this "resistor" is
defined by a table called "pullup", which uses "V" as the
independent variable (first column) and "I" as the
dependent variable (next column).  It could have
typ/min/max as IBIS does now.

A fixed parameterized value could be ...

Cc  (P1  0)  C=c_comp

This one says to use the value "c_comp", which is a scalar.

For generating signals, something time dependent is needed
...

Rpu  (A1  A2)  I=pullup[V,T]

This one says there is a family of tables.

For sensing a value, a "trigger" element could be used ...

T44  V[A1] > Vhigh  ||  V[A1] < Vlow
T55  V[B4] == 3.5

T44 generates a "trigger" when the voltage at node A1 rises
through Vhigh or falls through Vlow.  T55 generates a
trigger when V[B4] crosses 3.5 from either direction. 
These triggers are passed to  anything with a time
dependency to start a waveform.


An optional parameter could be expressed with the "or" 
( || ) operator.

Rpower (pin pcr) R=Rpower || infinity

The resistor Rpower left open if the parameter is missing.

Vpcr (pcr 0) V=Power_clamp_reference || Voltage_range

The voltage source Vpcr gets its value from either
Power_clamp_reference (IBIS 2 or later) or Voltage_range
(IBIS 1)


Other components like transmission lines could also be
included.

It should be apparent that this is capable of generating
all of the structures that are now used by the IBIS
[Model], or are being considered.

More is needed to address the array nature of the
[Component], [Package Model], or [EBD].

One thought is that the component itself could have an
array form ...

Lpin[1:36]  (A[1:36]  B[1:36])  2.2n

This generates 36 inductors ...

Lpin1  (A1  B1)  2.2n
Lpin2  (A2  B2)  2.2n
....

this is based on the syntax where [1:36] means a sequence
of numbers 1,2,..36. 

Coupling might be represented this way ...

Cc[1:35]  B[1:35]  B[2:36]  .5p


It could also use inheritance to minimize the duplication.

We also need to say what this is and how it is called.

Here is a start showing usage ...

[Begin Structure] Model_base (pin, pwr_clamp_e, gnd_clamp_e)
Rpc (pin pwr_clamp) I=POWER_Clamp[-v]
Rgc (pin gnd_clamp) I=GND_Clamp[v]
Cttpwr (pin pwr_clamp) C = TTpower * I(Rpc) / VT || 0
Cttgnd (pin gnd_clamp) C = TTpower * I(Rgc) / VT || 0
Ccomp (pin 0) C=Ccomp
if (pwr_clamp_e){
  pwr_clamp = pwr_clamp_e
}else{
  Vpcr (pwr_clamp 0) V = Power_clamp_reference || Voltage_range
}
if (gnd_clamp_e){
  gnd_clamp = gnd_clamp_e
}else{
  Vgcr (gnd_clamp 0) V = GND_clamp_reference || 0
}
[End Structure]

[Begin Structure] Terminator (pin, pwr_clamp, gnd_clamp)
inherit Model_base (pin, pwr_clamp, gnd_clamp)
Rac (pin t1) R = Rac || 0
Cac (t1 0) C = Cac || 0
Rpwr (pin pwr_clamp) R = Rpower || infinity
Rgnd (pin gnd_clamp) R = Rgnd || infinity
[End Structure]

[Model] b1000_terminator
Model_type = Terminator
[POWER_Clamp]
.....
| exactly the same as you define a Terminator now!  100% compatible.



I have structures for some of IBIS 3.2.  So far, the only
"element" I needed that isn't trivial is a "driver" that
accomodates rising and falling waveforms with pullup and
pulldown as a single element.  The only reason this one is
needed is for backward compatibility.  It is amazing how
simple and clear some of the models are with this approach.

This is a start.  If we complete this, I believe it can
solve most of the existing IBIS problems, and address new
ones nobody thought of yet.  Also, it provides the added
functionality of IMEC, while maintaining the behavioral
nature of IBIS.  It is also easy to implement, much easier
than the existing IBIS 3.2.

If it stands a reasonable chance of being adopted, I
volunteer to write a complete spec based on this, and an
initial set of compatibility structures.

From owner-ibis  Thu Dec  2 16:35:51 1999
Received: from odin.acuson.com (odin.acuson.com [157.226.230.71]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA23797 for <ibis@eda.org>; Thu, 2 Dec 1999 16:35:51 -0800 (PST)
Received: from acuson.com ([157.226.41.35]) by odin.acuson.com
          (Netscape Messaging Server 3.54)  with ESMTP id AAA2ED9;
          Thu, 2 Dec 1999 16:38:56 -0800
Sender: "Kim Helliwell" <khelliwe@acuson.com>
Message-ID: <3847102B.88211578@acuson.com>
Date: Thu, 02 Dec 1999 16:34:51 -0800
From: Kim Helliwell <khelliwe@acuson.com>
Organization: Acuson
X-Mailer: Mozilla 4.04 [en] (X11; U; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: micohen@us.ibm.com
CC: ibis@eda.org
Subject: Re: SPICE-To-IBIS Version 3 (S2IBIS3) Proposal Now Available For Review
References: <85256839.0079BC58.00@d54mta04.raleigh.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

micohen@us.ibm.com wrote:
> 
> Hello everyone!
> 
> I would like to announce the SPICE-To-IBIS Version 3 (S2IBIS3) Project
> Proposal to everyone who was not present at the last IBIS Open Forum
> Meeting held last Friday, November 26, 1999.  The proposal can be found on
> the IBIS Home Page:
>   http://www.eia.org/eig/ibis/ibis.htm
> or directly at:
>   http://www.eda.org/pub/ibis/s2ibis3/
> 
> Please review the "s2ibis3_PR_1_00.txt" document; if you have any comments,
> please post them on this reflector to help stimulate discussions.
> 
> Again, let me thank everyone who participated on the subcommittee; your
> hard work is much appreciated!  The members of this subcommittee are:
>     Michael Cohen (Chairperson)     IBM Personal Systems Group
>     Syed Huq                        Cisco Systems
>     Christian Klein (Secretary)     Fairchild Semiconductors
>     Mike LaBonte                    Cadence Design Systems
>     Arpad Muranyi                   Intel Corporation
>     Bob Ross                        Mentor Graphics
>     Mohamed Nasef                   Mentor Graphics
>     Jerry Hayes                     IBM
>     Sherif Hammad                   Mentor Graphics
> 
> Regards,
> Michael Cohen
> Chairperson, SPICE To IBIS Subcommittee


Regarding paragraph 3.6.2 concerning incremental changes:

It's not clear whether the iterate feature is the default, or whether
it's even controllable by the user.  At least, my (admittedly small) use
of S2IBIS2 so far suggests that the only way to override the iterate
feature is to rm all the generated files.

I'd like (if it's not already part of the spec, and it doesn't appear to
be) a simple command-line flag or some other simple mechanism to select
iterate or not, as the user chooses.  There really are some times when
incremental changes are *NOT* wanted, and I don't think I should have
to rm the files in order to force a full regeneration of a model.
-- 
Kim Helliwell
Senior CAE Engineer
Acuson Corporation
Phone: 650 694 5030  FAX: 650 943 7260
From owner-ibis  Thu Dec  2 18:19:18 1999
Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id SAA24087 for <ibis@eda.org>; Thu, 2 Dec 1999 18:19:17 -0800 (PST)
Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id SAA21516; Thu, 2 Dec 1999 18:18:08 -0800 (PST)
Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R)
	id SAA16475; Thu, 2 Dec 1999 18:18:07 -0800 (PST)
Sender: bob_ross@mentorg.com
Message-ID: <3847285E.634B27C3@mentor.com>
Date: Thu, 02 Dec 1999 18:18:06 -0800
From: Bob Ross <bob_ross@mentorg.com>
X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: albertd@hyperlynx.com, ibis@eda.org
Subject: Re: Future directions for IBIS
References: <3839903F.CB7632F2@mentor.com> <99120213303306.01159@oliver.al.dynip.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Al:

We have had some interesting discussions on future
directions for IBIS.  Thank you all for participating,
and I welcome more discussion of the subject.

You have provided another proposal along with some excellent
arguments that need to be considered by the IBIS Committee.

Bob Ross
Mentor Graphics



Al Davis wrote:
> 
> Try this:
> 
> (embellishing on the seed note by Stephen Peters)
> 
> The IBIS model is not truly behavioral, but a parameter
> list for pre-defined structures.
> 
> Model ...
>   input, output, i/o, open drain, etc.
> Augmentations to the model ...
>   driver schedule, bus hold, dynamic clamp ...
> Containers ...
>   component. package model, ebd, connector
> 
> We have all suffered through the need for yet another
> structure to be added to the spec, or the discovery that
> something is missing,  unclear, or difficult to implement.
> 
> My proposal is to have essentially two sections, a
> parameter section functionally similar to the existing
> IBIS, and a structure definition section that defines these
> structures.  By doing this, this structure definition is
> removed from the committee and simulator designer, and made
> available to the model developer.  A netlist like language
> could be used to define them.
> 
> To provide a migration path, and prove the appropriateness
> of the new language, a set of structure definitions could
> be provided with any conforming IBIS simulator, in the same
> sense that any C compiler provides a standard library.
> These would be provided in source form so they could be
> used by model developers as a prototype for developing
> their new structures.  I have these for some of the ibis
> model types.  So far, I was able to define structures that
> can be expanded by an existing IBIS [Model] section, for
> 100% backward compatibility.
> 
> As an added benefit, we could provide these structure
> definitions for 1.0, 1.1, 2.0, 2.1, 3.0, 3.1, 3.2 ......
> with little additional effort.  All of the proposed BIRDs
> can be added to the structure with trivial effort.
> 
> This structure should be netlist style, and can be inspired
> by the Spice style.  As an alternate to providing a value
> for any component, a parameter name could be specified.
> The values for the parameter would be provided in the
> parameter section, which would look much like  the existing
> IBIS format.  Parameters could be scalars, tables,
> multi-dimensional tables, or equations.  They may or may
> not have ranges, depending on the application.
> 
> Since this will be processed, the format does not need to
> conform to any particular Spice implementation.  It can
> provide component types and parameters that do not exist in
> standard Spice.  It is not much work for a simulator
> developer to add the necessary functionality to Spice.  It
> also should be not much work to generalize the simpler
> interconnect simulators to take these components.
> 
> Some elements to provide ...
> 
> The classic R, L, C, V, I, E, G .. both in the simple form,
> with a value, and an advanced form where the value is a
> parameter, for example ...
> 
> Rpu  (A1  A2)   I=pullup[V]
> 
> This says that the v/i characteristic of this "resistor" is
> defined by a table called "pullup", which uses "V" as the
> independent variable (first column) and "I" as the
> dependent variable (next column).  It could have
> typ/min/max as IBIS does now.
> 
> A fixed parameterized value could be ...
> 
> Cc  (P1  0)  C=c_comp
> 
> This one says to use the value "c_comp", which is a scalar.
> 
> For generating signals, something time dependent is needed
> ...
> 
> Rpu  (A1  A2)  I=pullup[V,T]
> 
> This one says there is a family of tables.
> 
> For sensing a value, a "trigger" element could be used ...
> 
> T44  V[A1] > Vhigh  ||  V[A1] < Vlow
> T55  V[B4] == 3.5
> 
> T44 generates a "trigger" when the voltage at node A1 rises
> through Vhigh or falls through Vlow.  T55 generates a
> trigger when V[B4] crosses 3.5 from either direction.
> These triggers are passed to  anything with a time
> dependency to start a waveform.
> 
> An optional parameter could be expressed with the "or"
> ( || ) operator.
> 
> Rpower (pin pcr) R=Rpower || infinity
> 
> The resistor Rpower left open if the parameter is missing.
> 
> Vpcr (pcr 0) V=Power_clamp_reference || Voltage_range
> 
> The voltage source Vpcr gets its value from either
> Power_clamp_reference (IBIS 2 or later) or Voltage_range
> (IBIS 1)
> 
> Other components like transmission lines could also be
> included.
> 
> It should be apparent that this is capable of generating
> all of the structures that are now used by the IBIS
> [Model], or are being considered.
> 
> More is needed to address the array nature of the
> [Component], [Package Model], or [EBD].
> 
> One thought is that the component itself could have an
> array form ...
> 
> Lpin[1:36]  (A[1:36]  B[1:36])  2.2n
> 
> This generates 36 inductors ...
> 
> Lpin1  (A1  B1)  2.2n
> Lpin2  (A2  B2)  2.2n
> ....
> 
> this is based on the syntax where [1:36] means a sequence
> of numbers 1,2,..36.
> 
> Coupling might be represented this way ...
> 
> Cc[1:35]  B[1:35]  B[2:36]  .5p
> 
> It could also use inheritance to minimize the duplication.
> 
> We also need to say what this is and how it is called.
> 
> Here is a start showing usage ...
> 
> [Begin Structure] Model_base (pin, pwr_clamp_e, gnd_clamp_e)
> Rpc (pin pwr_clamp) I=POWER_Clamp[-v]
> Rgc (pin gnd_clamp) I=GND_Clamp[v]
> Cttpwr (pin pwr_clamp) C = TTpower * I(Rpc) / VT || 0
> Cttgnd (pin gnd_clamp) C = TTpower * I(Rgc) / VT || 0
> Ccomp (pin 0) C=Ccomp
> if (pwr_clamp_e){
>   pwr_clamp = pwr_clamp_e
> }else{
>   Vpcr (pwr_clamp 0) V = Power_clamp_reference || Voltage_range
> }
> if (gnd_clamp_e){
>   gnd_clamp = gnd_clamp_e
> }else{
>   Vgcr (gnd_clamp 0) V = GND_clamp_reference || 0
> }
> [End Structure]
> 
> [Begin Structure] Terminator (pin, pwr_clamp, gnd_clamp)
> inherit Model_base (pin, pwr_clamp, gnd_clamp)
> Rac (pin t1) R = Rac || 0
> Cac (t1 0) C = Cac || 0
> Rpwr (pin pwr_clamp) R = Rpower || infinity
> Rgnd (pin gnd_clamp) R = Rgnd || infinity
> [End Structure]
> 
> [Model] b1000_terminator
> Model_type = Terminator
> [POWER_Clamp]
> .....
> | exactly the same as you define a Terminator now!  100% compatible.
> 
> I have structures for some of IBIS 3.2.  So far, the only
> "element" I needed that isn't trivial is a "driver" that
> accomodates rising and falling waveforms with pullup and
> pulldown as a single element.  The only reason this one is
> needed is for backward compatibility.  It is amazing how
> simple and clear some of the models are with this approach.
> 
> This is a start.  If we complete this, I believe it can
> solve most of the existing IBIS problems, and address new
> ones nobody thought of yet.  Also, it provides the added
> functionality of IMEC, while maintaining the behavioral
> nature of IBIS.  It is also easy to implement, much easier
> than the existing IBIS 3.2.
> 
> If it stands a reasonable chance of being adopted, I
> volunteer to write a complete spec based on this, and an
> initial set of compatibility structures.
From owner-ibis  Fri Dec  3 08:42:41 1999
Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA01046 for <ibis@eda.org>; Fri, 3 Dec 1999 08:42:40 -0800 (PST)
Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id IAA06046; Fri, 3 Dec 1999 08:41:03 -0800 (PST)
Received: from mentorg.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R)
	id IAA24891; Fri, 3 Dec 1999 08:41:02 -0800 (PST)
Sender: chris_reid@mentorg.com
Message-ID: <3847F29F.BF199669@mentorg.com>
Date: Fri, 03 Dec 1999 08:41:03 -0800
From: Christopher Reid <chris_reid@mentorg.com>
Organization: Mentor Graphics
X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Ross <bob_ross@mentorg.com>
CC: albertd@hyperlynx.com, ibis@eda.org
Subject: Re: Future directions for IBIS
References: <3839903F.CB7632F2@mentor.com> <99120213303306.01159@oliver.al.dynip.com> <3847285E.634B27C3@mentor.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Al & Stephen,

I like your ideas for a structure-oriented future for IBIS.
The comment that

> It
> also should be not much work to generalize the simpler
> interconnect simulators to take these components.

This is probably not true; but I do think it would be less
work to generalize a simulator once to take care of these
structures than to keep modifying simulators to take new
data types every time the IBIS spec changes.

Even if this approach is adopted, the comittee still needs
to define the standard structures for new devices and to
verify that these structures adequately represent the
devices they are supposed to mimmic.  Individual users
could vary from these standard structures, but for the
most part I would like to see publicly available models
following standard structures so that everyone has some
confidence that the results will be correct.

Chris

Bob Ross wrote:

> Al:
>
> We have had some interesting discussions on future
> directions for IBIS.  Thank you all for participating,
> and I welcome more discussion of the subject.
>
> You have provided another proposal along with some excellent
> arguments that need to be considered by the IBIS Committee.
>
> Bob Ross
> Mentor Graphics
>
> Al Davis wrote:
> >
> > Try this:
> >
> > (embellishing on the seed note by Stephen Peters)
> >
> > The IBIS model is not truly behavioral, but a parameter
> > list for pre-defined structures.
> >
> > Model ...
> >   input, output, i/o, open drain, etc.
> > Augmentations to the model ...
> >   driver schedule, bus hold, dynamic clamp ...
> > Containers ...
> >   component. package model, ebd, connector
> >
> > We have all suffered through the need for yet another
> > structure to be added to the spec, or the discovery that
> > something is missing,  unclear, or difficult to implement.
> >
> > My proposal is to have essentially two sections, a
> > parameter section functionally similar to the existing
> > IBIS, and a structure definition section that defines these
> > structures.  By doing this, this structure definition is
> > removed from the committee and simulator designer, and made
> > available to the model developer.  A netlist like language
> > could be used to define them.
> >
> > To provide a migration path, and prove the appropriateness
> > of the new language, a set of structure definitions could
> > be provided with any conforming IBIS simulator, in the same
> > sense that any C compiler provides a standard library.
> > These would be provided in source form so they could be
> > used by model developers as a prototype for developing
> > their new structures.  I have these for some of the ibis
> > model types.  So far, I was able to define structures that
> > can be expanded by an existing IBIS [Model] section, for
> > 100% backward compatibility.
> >
> > As an added benefit, we could provide these structure
> > definitions for 1.0, 1.1, 2.0, 2.1, 3.0, 3.1, 3.2 ......
> > with little additional effort.  All of the proposed BIRDs
> > can be added to the structure with trivial effort.
> >
> > This structure should be netlist style, and can be inspired
> > by the Spice style.  As an alternate to providing a value
> > for any component, a parameter name could be specified.
> > The values for the parameter would be provided in the
> > parameter section, which would look much like  the existing
> > IBIS format.  Parameters could be scalars, tables,
> > multi-dimensional tables, or equations.  They may or may
> > not have ranges, depending on the application.
> >
> > Since this will be processed, the format does not need to
> > conform to any particular Spice implementation.  It can
> > provide component types and parameters that do not exist in
> > standard Spice.  It is not much work for a simulator
> > developer to add the necessary functionality to Spice.  It
> > also should be not much work to generalize the simpler
> > interconnect simulators to take these components.
> >
> > Some elements to provide ...
> >
> > The classic R, L, C, V, I, E, G .. both in the simple form,
> > with a value, and an advanced form where the value is a
> > parameter, for example ...
> >
> > Rpu  (A1  A2)   I=pullup[V]
> >
> > This says that the v/i characteristic of this "resistor" is
> > defined by a table called "pullup", which uses "V" as the
> > independent variable (first column) and "I" as the
> > dependent variable (next column).  It could have
> > typ/min/max as IBIS does now.
> >
> > A fixed parameterized value could be ...
> >
> > Cc  (P1  0)  C=c_comp
> >
> > This one says to use the value "c_comp", which is a scalar.
> >
> > For generating signals, something time dependent is needed
> > ...
> >
> > Rpu  (A1  A2)  I=pullup[V,T]
> >
> > This one says there is a family of tables.
> >
> > For sensing a value, a "trigger" element could be used ...
> >
> > T44  V[A1] > Vhigh  ||  V[A1] < Vlow
> > T55  V[B4] == 3.5
> >
> > T44 generates a "trigger" when the voltage at node A1 rises
> > through Vhigh or falls through Vlow.  T55 generates a
> > trigger when V[B4] crosses 3.5 from either direction.
> > These triggers are passed to  anything with a time
> > dependency to start a waveform.
> >
> > An optional parameter could be expressed with the "or"
> > ( || ) operator.
> >
> > Rpower (pin pcr) R=Rpower || infinity
> >
> > The resistor Rpower left open if the parameter is missing.
> >
> > Vpcr (pcr 0) V=Power_clamp_reference || Voltage_range
> >
> > The voltage source Vpcr gets its value from either
> > Power_clamp_reference (IBIS 2 or later) or Voltage_range
> > (IBIS 1)
> >
> > Other components like transmission lines could also be
> > included.
> >
> > It should be apparent that this is capable of generating
> > all of the structures that are now used by the IBIS
> > [Model], or are being considered.
> >
> > More is needed to address the array nature of the
> > [Component], [Package Model], or [EBD].
> >
> > One thought is that the component itself could have an
> > array form ...
> >
> > Lpin[1:36]  (A[1:36]  B[1:36])  2.2n
> >
> > This generates 36 inductors ...
> >
> > Lpin1  (A1  B1)  2.2n
> > Lpin2  (A2  B2)  2.2n
> > ....
> >
> > this is based on the syntax where [1:36] means a sequence
> > of numbers 1,2,..36.
> >
> > Coupling might be represented this way ...
> >
> > Cc[1:35]  B[1:35]  B[2:36]  .5p
> >
> > It could also use inheritance to minimize the duplication.
> >
> > We also need to say what this is and how it is called.
> >
> > Here is a start showing usage ...
> >
> > [Begin Structure] Model_base (pin, pwr_clamp_e, gnd_clamp_e)
> > Rpc (pin pwr_clamp) I=POWER_Clamp[-v]
> > Rgc (pin gnd_clamp) I=GND_Clamp[v]
> > Cttpwr (pin pwr_clamp) C = TTpower * I(Rpc) / VT || 0
> > Cttgnd (pin gnd_clamp) C = TTpower * I(Rgc) / VT || 0
> > Ccomp (pin 0) C=Ccomp
> > if (pwr_clamp_e){
> >   pwr_clamp = pwr_clamp_e
> > }else{
> >   Vpcr (pwr_clamp 0) V = Power_clamp_reference || Voltage_range
> > }
> > if (gnd_clamp_e){
> >   gnd_clamp = gnd_clamp_e
> > }else{
> >   Vgcr (gnd_clamp 0) V = GND_clamp_reference || 0
> > }
> > [End Structure]
> >
> > [Begin Structure] Terminator (pin, pwr_clamp, gnd_clamp)
> > inherit Model_base (pin, pwr_clamp, gnd_clamp)
> > Rac (pin t1) R = Rac || 0
> > Cac (t1 0) C = Cac || 0
> > Rpwr (pin pwr_clamp) R = Rpower || infinity
> > Rgnd (pin gnd_clamp) R = Rgnd || infinity
> > [End Structure]
> >
> > [Model] b1000_terminator
> > Model_type = Terminator
> > [POWER_Clamp]
> > .....
> > | exactly the same as you define a Terminator now!  100% compatible.
> >
> > I have structures for some of IBIS 3.2.  So far, the only
> > "element" I needed that isn't trivial is a "driver" that
> > accomodates rising and falling waveforms with pullup and
> > pulldown as a single element.  The only reason this one is
> > needed is for backward compatibility.  It is amazing how
> > simple and clear some of the models are with this approach.
> >
> > This is a start.  If we complete this, I believe it can
> > solve most of the existing IBIS problems, and address new
> > ones nobody thought of yet.  Also, it provides the added
> > functionality of IMEC, while maintaining the behavioral
> > nature of IBIS.  It is also easy to implement, much easier
> > than the existing IBIS 3.2.
> >
> > If it stands a reasonable chance of being adopted, I
> > volunteer to write a complete spec based on this, and an
> > initial set of compatibility structures.

From owner-ibis  Fri Dec  3 10:12:45 1999
Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA01310 for <ibis@eda.org>; Fri, 3 Dec 1999 10:12:44 -0800 (PST)
Received: from jasper.cisco.com (jasper.cisco.com [171.69.198.63])
	by jasper.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id KAA16120;
	Fri, 3 Dec 1999 10:11:02 -0800 (PST)
Message-Id: <199912031811.KAA16120@jasper.cisco.com>
Date: Fri, 3 Dec 1999 10:11:02 -0800 (PST)
From: Syed Huq <shuq@cisco.com>
Reply-To: Syed Huq <shuq@cisco.com>
Subject: Re: SPICE-To-IBIS Version 3 (S2IBIS3) Proposal Now Available For Review
To: micohen@us.ibm.com, khelliwe@acuson.com
Cc: ibis@eda.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: bjnxHm/Pb92BJZmt+W4DoA==
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc 

Kim,

In the present s2ibis2, [Iterate] is optional. If it is not added in
the header file (.s2i), then it is not used. This is what the documentation
says:(/doc/s2ibis2.txt)

 [Iterate]

        Optional.
        Default: none.
        
You could also use the [Cleanup] keyword and let s2ibis2 get rid of all
spi, out , st0, msg files after successful simulation. 
See below:(/doc/s2ibis2.txt)

 [Cleanup]

        Optional.
        Default: none.

        When this command is specified, s2ibis2 will delete all of the
        spice input, output and message files as it proceeds. This is
        good to use when you think the IBIS file is done and you want to
        clean up the working directory.


Regards,
Syed
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Syed B. Huq           shuq@cisco.com  ~
SI Engineer/Technical Leader          ~
Cisco Systems, Inc.  ELB Group        ~
Ph:(408)525-3399   Fax:(408)526-5504  ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

> 
> Regarding paragraph 3.6.2 concerning incremental changes:
> 
> It's not clear whether the iterate feature is the default, or whether
> it's even controllable by the user.  At least, my (admittedly small) use
> of S2IBIS2 so far suggests that the only way to override the iterate
> feature is to rm all the generated files.
> 
> I'd like (if it's not already part of the spec, and it doesn't appear to
> be) a simple command-line flag or some other simple mechanism to select
> iterate or not, as the user chooses.  There really are some times when
> incremental changes are *NOT* wanted, and I don't think I should have
> to rm the files in order to force a full regeneration of a model.
> -- 
> Kim Helliwell
> Senior CAE Engineer
> Acuson Corporation
> Phone: 650 694 5030  FAX: 650 943 7260
> 



From owner-ibis  Fri Dec  3 13:23:12 1999
Received: from mta2.snfc21.pbi.net (mta2.snfc21.pbi.net [206.13.28.123]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA02471 for <ibis@vhdl.org>; Fri, 3 Dec 1999 13:23:11 -0800 (PST)
Received: from postoffice.pacbell.net ([209.79.182.172])
 by mta2.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8)
 with ESMTP id <0FM60035COHV54@mta2.snfc21.pbi.net> for ibis@vhdl.org; Fri,
 3 Dec 1999 13:17:56 -0800 (PST)
Date: Fri, 03 Dec 1999 13:16:51 -0800
From: Jon Powell <jonp@pacbell.net>
Subject: Designcon Signs
To: "ibis@vhdl.org" <ibis@vhdl.org>
Reply-to: jpowell@viewlogic.com
Message-id: <38483343.C41912C6@postoffice.pacbell.net>
MIME-version: 1.0
X-Mailer: Mozilla 4.05 [en]C-PBI-NC404  (Win95; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit

For those of you who wish to send me new signage for Designcon: (should
have sent this out with the last email ...)

Jon Powell
Viewlogic
1369 Del Norte Rd.
Camarillo CA. 93010

--
Jon Powell
Director of HSSD Consulting Services
Viewlogic Systems, INC.
805 988 8250


From owner-ibis  Fri Dec  3 14:04:04 1999
Received: from isis.vlsi.com (relayhost.vlsi.com [63.194.140.24]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA02697 for <ibis@eda.org>; Fri, 3 Dec 1999 14:04:03 -0800 (PST)
Received: (from smtp@localhost)
	by isis.vlsi.com (8.9.1a/8.9.1) id OAA05784
	for <ibis@eda.org>; Fri, 3 Dec 1999 14:03:18 -0800 (PST)
X-Authentication-Warning: isis.vlsi.com: smtp set sender to <dc.sessions@vlsi.com> using -f
Received: from <dc.sessions@vlsi.com> (tem-pbx1.tempe.vlsi.com [134.27.128.26]) by isis via smap (V2.0)
	id xma005775; Fri, 3 Dec 99 14:03:11 -0800
Received: from vlsi.com (witsend.tempe.vlsi.com [134.27.133.12]) by tem-pbx1.tempe.vlsi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id YD9V70G2; Fri, 3 Dec 1999 15:03:10 -0700
Sender: dsession@isis.vlsi.com
Message-ID: <38483E1C.B2BC6DB2@vlsi.com>
Date: Fri, 03 Dec 1999 15:03:08 -0700
From: "D. C. Sessions" <dc.sessions@vlsi.com>
Organization: VLSI Technology Inc.
X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.6 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: IBIS Mailing list <ibis@eda.org>
Subject: JEDEC JC-16 news
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I got back just a bit late to join the conference call this morning.
Anyway, JEDEC's memory-related committees met this week, including
JC-16 (which is more or less tasked with signal-integrity issues
including modeling.)  A few of the high points:

1.      JC-16.2 will be organizing a collection of subsystem models
        for use in evaluating proposed new interfaces.
2.      Return-path effects (SSO, jitter) are the primary limiters
        on DDR-II performance.
3.      JC-16 needs to use IBIS to specify permitted I/O behavior.
        A working group will meet to address the use of IBIS for
        standards specification the day after the DesignCon IBIS
        summit in the Bay Area (Tues 1 Feb).  It is hoped that DC
        won't be the only IBIS member present.
4.      It looks like JEDEC will be reorganizing the website to
        make thiings easier to find.  Unless you're all a lot
        smarter than I am, this is welcome news indeed.
5.      New chair of JC-16: D C Sessions

-- 
D. C. Sessions
dc.sessions@vlsi.com
From owner-ibis  Fri Dec  3 15:16:28 1999
Received: from isis.vlsi.com (relayhost.vlsi.com [63.194.140.24]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA02876 for <ibis@eda.org>; Fri, 3 Dec 1999 15:16:22 -0800 (PST)
Received: (from smtp@localhost)
	by isis.vlsi.com (8.9.1a/8.9.1) id PAA08801
	for <ibis@eda.org>; Fri, 3 Dec 1999 15:15:41 -0800 (PST)
X-Authentication-Warning: isis.vlsi.com: smtp set sender to <dc.sessions@vlsi.com> using -f
Received: from <dc.sessions@vlsi.com> (tem-pbx1.tempe.vlsi.com [134.27.128.26]) by isis via smap (V2.0)
	id xma008773; Fri, 3 Dec 99 15:15:26 -0800
Received: from vlsi.com (witsend.tempe.vlsi.com [134.27.133.12]) by tem-pbx1.tempe.vlsi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id YD9V702G; Fri, 3 Dec 1999 16:15:24 -0700
Sender: dsession@isis.vlsi.com
Message-ID: <38484F0C.865EB268@vlsi.com>
Date: Fri, 03 Dec 1999 16:15:24 -0700
From: "D. C. Sessions" <dc.sessions@vlsi.com>
Organization: VLSI Technology Inc.
X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.6 sun4m)
X-Accept-Language: en
MIME-Version: 1.0
To: IBIS Mailing list <ibis@eda.org>
Subject: YAFI
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Yet Another Future IBIS

I've been looking at this from the point of enumerating IBIS' strengths
and weaknesses.  As follows:

1)      IBIS strengths
        Good at simulation of classical CMOS drivers
        Adequate for TTL receivers
        OK for passing device pinouts
        OK for uncoupled package parasitics
        OK for selectable drive strength
2)      IBIS weaknesses
        No return-path models
        Poor receiver modeling
        No coupled parasitics
        No coupled drivers (e.g. Open-drain current-mode differential)
        No present method to model source modulation (gate starvation)

The trouble is, the very things that IBIS doesn't do well (e.g. return
path modeling) are exactly the things that are turning out to be the
limiting factors in newer systems (e.g. source-synchronous systems.)

As several others have pointed out, a lot of this isn't so much a problem
with IBIS _per_se_ as it is a matter of IBIS taking on a job which isn't
fundamentally behavioral and where a structural interconnect model works
quite well.  After all it's not as though manufacurers are worried about
giving out metal-interconnect data that can be found by anyone with a
DVM.  Which argues, to me, that we should quit trying to reinvent the wheel.

3)      Proposed future course
        Use IBIS [Model] for drivers and receivers
        Enhance IBIS as needed to model input behavior
        Enhance IBIS as needed to model gate starvation
        Use EDIF netlist to model on-chip return paths
        Use connector syntax or netlist to model package parasitics

I'm not religious about the EDIF part.  An extended SPICE format that
allows distributed parasitics would be just fine by me; maybe we should
provide for both in the same way that HDLs can be both behavioral and
structural.  The main thing is that a netlist-like format is really
necessary to define the return-path and coupling effects that are taking
over our applications.

Now the radical part to me is the question of whether the result will
be IBIS-calling-other-formats or other-formats-calling-IBIS.  From
a heirarchical point of view, IBIS is at the lowest level of detail
and you get all kinds of inversions trying to do it any other way.
If there isn't presently some appropriate system-interconnect language
that still doesn't mean that we should somehow make IBIS extend to both
ends of the scale; it means that an appropriate top-level language needs
to be created.  IBIS -- whatever it becomes -- stays at the bottom of
the abstraction stack.

Decoupling the need for a system-interconnect language from IBIS per se
allows us to solve the problem without burdening the effort with the
addition of another, perhaps nonbeneficial, constraint.  The connector
group seems to have done just that with good results.

-- 
D. C. Sessions
dc.sessions@vlsi.com
From owner-ibis  Fri Dec  3 15:41:38 1999
Received: from hebe.or.intel.com (hebe.or.intel.com [134.134.248.4]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA02957 for <ibis@vhdl.org>; Fri, 3 Dec 1999 15:41:38 -0800 (PST)
Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200])
	by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.11 1999/11/10 17:27:15 spurcell Exp $) with ESMTP id PAA11258;
	Fri, 3 Dec 1999 15:51:41 -0800 (PST)
Received: from xtg801.pdx.intel.com (xtg801.pdx.intel.com [134.134.114.35])
	by ichips-jf.jf.intel.com (8.9.1a/8.9.1/d: internal.m4,v 1.2 1998/11/09 19:18:37 iwep Exp iwep $) with ESMTP id PAA22193;
	Fri, 3 Dec 1999 15:40:58 -0800 (PST)
Received: from ichips.intel.com (localhost.pdx.intel.com [127.0.0.1])
	by xtg801.pdx.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) with ESMTP id PAA00664;
	Fri, 3 Dec 1999 15:28:28 -0800 (PST)
Message-Id: <199912032328.PAA00664@xtg801.pdx.intel.com>
X-Mailer: exmh version 2.0delta 6/3/97
To: albertd@hyperlynx.com
cc: ibis@vhdl.org
Subject: Re: Future directions for IBIS 
In-reply-to: Your message of "Thu, 02 Dec 1999 13:03:44 PST."
             <99120213303306.01159@oliver.al.dynip.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 03 Dec 1999 15:28:27 -0800
From: Stephen Peters <sjpeters@ichips.intel.com>


Hello Al:

  This is a very intriguing proposal, especially with its potential for making 
the IBIS base model extensible.  If I understand correctly, what you are 
proposing is that the current IBIS prototype model be explicitly defined and 
documented by these simulation structures, and a user is free to create new 
structures as the need arises.  I especially like the way you did the nodal 
language, and the fact that you slipped in some programming constructs.

Just a couple of thoughts:

1.  There is still the problem of incorporating the package
power distribution and pin to pin coupling information.  The 
IBIS-X proposal took the approach of mapping component power/gnd pins
to a buffers power/gnd nodes, then allowing that buffer to
be made up of models of the package power distribution and the actual 
buffer.  I'm guessing your 'simulation structures' would still
have to be incorporated into an overall model/sub-model structure.

2.  (This thought courtesy of Scott McMorrow).  One item that I have not 
seen any proposal address is specifying timings *between* 
buffers.  For example, suppose there is a group of nine buffers that are
used in a source synchronous configurations. How does a component model tell a 
simulator (for example) pins 1-8 are the data, pin 9 is the strobe, and there 
is
Xns delay between the data bus and strobe?

Again, thanks for the thought provoking proposal.

   Regards,
   Stephen Peters
   Intel Corp.
  

> Try this:
> 
> (embellishing on the seed note by Stephen Peters)
> 
> The IBIS model is not truly behavioral, but a parameter
> list for pre-defined structures.
> 
> Model ...
>   input, output, i/o, open drain, etc.
> Augmentations to the model ...
>   driver schedule, bus hold, dynamic clamp ...
> Containers ...
>   component. package model, ebd, connector
> 
> We have all suffered through the need for yet another
> structure to be added to the spec, or the discovery that
> something is missing,  unclear, or difficult to implement.
> 
> 
> My proposal is to have essentially two sections, a
> parameter section functionally similar to the existing
> IBIS, and a structure definition section that defines these
> structures.  By doing this, this structure definition is
> removed from the committee and simulator designer, and made
> available to the model developer.  A netlist like language
> could be used to define them.
> 
> To provide a migration path, and prove the appropriateness
> of the new language, a set of structure definitions could
> be provided with any conforming IBIS simulator, in the same
> sense that any C compiler provides a standard library. 
> These would be provided in source form so they could be
> used by model developers as a prototype for developing
> their new structures.  I have these for some of the ibis
> model types.  So far, I was able to define structures that
> can be expanded by an existing IBIS [Model] section, for
> 100% backward compatibility.
> 
> As an added benefit, we could provide these structure
> definitions for 1.0, 1.1, 2.0, 2.1, 3.0, 3.1, 3.2 ...... 
> with little additional effort.  All of the proposed BIRDs
> can be added to the structure with trivial effort.
> 
> This structure should be netlist style, and can be inspired
> by the Spice style.  As an alternate to providing a value
> for any component, a parameter name could be specified. 
> The values for the parameter would be provided in the
> parameter section, which would look much like  the existing
> IBIS format.  Parameters could be scalars, tables,
> multi-dimensional tables, or equations.  They may or may
> not have ranges, depending on the application.
> 
> Since this will be processed, the format does not need to
> conform to any particular Spice implementation.  It can
> provide component types and parameters that do not exist in
> standard Spice.  It is not much work for a simulator
> developer to add the necessary functionality to Spice.  It
> also should be not much work to generalize the simpler
> interconnect simulators to take these components.
> 
> Some elements to provide ...
> 
> The classic R, L, C, V, I, E, G .. both in the simple form,
> with a value, and an advanced form where the value is a
> parameter, for example ...
> 
> Rpu  (A1  A2)   I=pullup[V]
> 
> This says that the v/i characteristic of this "resistor" is
> defined by a table called "pullup", which uses "V" as the
> independent variable (first column) and "I" as the
> dependent variable (next column).  It could have
> typ/min/max as IBIS does now.
> 
> A fixed parameterized value could be ...
> 
> Cc  (P1  0)  C=c_comp
> 
> This one says to use the value "c_comp", which is a scalar.
> 
> For generating signals, something time dependent is needed
> ...
> 
> Rpu  (A1  A2)  I=pullup[V,T]
> 
> This one says there is a family of tables.
> 
> For sensing a value, a "trigger" element could be used ...
> 
> T44  V[A1] > Vhigh  ||  V[A1] < Vlow
> T55  V[B4] == 3.5
> 
> T44 generates a "trigger" when the voltage at node A1 rises
> through Vhigh or falls through Vlow.  T55 generates a
> trigger when V[B4] crosses 3.5 from either direction. 
> These triggers are passed to  anything with a time
> dependency to start a waveform.
> 
> 
> An optional parameter could be expressed with the "or" 
> ( || ) operator.
> 
> Rpower (pin pcr) R=Rpower || infinity
> 
> The resistor Rpower left open if the parameter is missing.
> 
> Vpcr (pcr 0) V=Power_clamp_reference || Voltage_range
> 
> The voltage source Vpcr gets its value from either
> Power_clamp_reference (IBIS 2 or later) or Voltage_range
> (IBIS 1)
> 
> 
> Other components like transmission lines could also be
> included.
> 
> It should be apparent that this is capable of generating
> all of the structures that are now used by the IBIS
> [Model], or are being considered.
> 
> More is needed to address the array nature of the
> [Component], [Package Model], or [EBD].
> 
> One thought is that the component itself could have an
> array form ...
> 
> Lpin[1:36]  (A[1:36]  B[1:36])  2.2n
> 
> This generates 36 inductors ...
> 
> Lpin1  (A1  B1)  2.2n
> Lpin2  (A2  B2)  2.2n
> ....
> 
> this is based on the syntax where [1:36] means a sequence
> of numbers 1,2,..36. 
> 
> Coupling might be represented this way ...
> 
> Cc[1:35]  B[1:35]  B[2:36]  .5p
> 
> 
> It could also use inheritance to minimize the duplication.
> 
> We also need to say what this is and how it is called.
> 
> Here is a start showing usage ...
> 
> [Begin Structure] Model_base (pin, pwr_clamp_e, gnd_clamp_e)
> Rpc (pin pwr_clamp) I=POWER_Clamp[-v]
> Rgc (pin gnd_clamp) I=GND_Clamp[v]
> Cttpwr (pin pwr_clamp) C = TTpower * I(Rpc) / VT || 0
> Cttgnd (pin gnd_clamp) C = TTpower * I(Rgc) / VT || 0
> Ccomp (pin 0) C=Ccomp
> if (pwr_clamp_e){
>   pwr_clamp = pwr_clamp_e
> }else{
>   Vpcr (pwr_clamp 0) V = Power_clamp_reference || Voltage_range
> }
> if (gnd_clamp_e){
>   gnd_clamp = gnd_clamp_e
> }else{
>   Vgcr (gnd_clamp 0) V = GND_clamp_reference || 0
> }
> [End Structure]
> 
> [Begin Structure] Terminator (pin, pwr_clamp, gnd_clamp)
> inherit Model_base (pin, pwr_clamp, gnd_clamp)
> Rac (pin t1) R = Rac || 0
> Cac (t1 0) C = Cac || 0
> Rpwr (pin pwr_clamp) R = Rpower || infinity
> Rgnd (pin gnd_clamp) R = Rgnd || infinity
> [End Structure]
> 
> [Model] b1000_terminator
> Model_type = Terminator
> [POWER_Clamp]
> .....
> | exactly the same as you define a Terminator now!  100% compatible.
> 
> 
> 
> I have structures for some of IBIS 3.2.  So far, the only
> "element" I needed that isn't trivial is a "driver" that
> accomodates rising and falling waveforms with pullup and
> pulldown as a single element.  The only reason this one is
> needed is for backward compatibility.  It is amazing how
> simple and clear some of the models are with this approach.
> 
> This is a start.  If we complete this, I believe it can
> solve most of the existing IBIS problems, and address new
> ones nobody thought of yet.  Also, it provides the added
> functionality of IMEC, while maintaining the behavioral
> nature of IBIS.  It is also easy to implement, much easier
> than the existing IBIS 3.2.
> 
> If it stands a reasonable chance of being adopted, I
> volunteer to write a complete spec based on this, and an
> initial set of compatibility structures.


From owner-ibis  Fri Dec  3 15:50:55 1999
Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA02975 for <ibis@eda.org>; Fri, 3 Dec 1999 15:50:54 -0800 (PST)
Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id PAA13694; Fri, 3 Dec 1999 15:49:44 -0800 (PST)
Received: from mentorg.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R)
	id PAA22902; Fri, 3 Dec 1999 15:49:43 -0800 (PST)
Sender: chris_reid@mentorg.com
Message-ID: <38485718.85E06B58@mentorg.com>
Date: Fri, 03 Dec 1999 15:49:44 -0800
From: Christopher Reid <chris_reid@mentorg.com>
Organization: Mentor Graphics
X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "D. C. Sessions" <dc.sessions@vlsi.com>
CC: IBIS Mailing list <ibis@eda.org>
Subject: Re: YAFI
References: <38484F0C.865EB268@vlsi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello,

Mostly I agree with D.C.  A netlist type structure is the only
sensible route forward; otherwise IBIS will be burdened with
frequent changes to take account of the latest ideas of how
to model these effects (which we are already seeing in the
proposals to split up C_comp.)

I'll vote for an extended SPICE syntax because I think that
is most natural for this problem.  We could make IBIS devices
that already exist into subcircuits callable by this syntax,
or we could redefine the current structures using the new
syntax.  I don't agree that IBIS is at the bottom of the abstraction
hierarchy because it already contains some fairly complicated
constructions.  The bottom of the hierarchy is the IV curves,
threshold detectors, etc.

Chris

"D. C. Sessions" wrote:

> Yet Another Future IBIS
>
> I've been looking at this from the point of enumerating IBIS' strengths
> and weaknesses.  As follows:
>
> 1)      IBIS strengths
>         Good at simulation of classical CMOS drivers
>         Adequate for TTL receivers
>         OK for passing device pinouts
>         OK for uncoupled package parasitics
>         OK for selectable drive strength
> 2)      IBIS weaknesses
>         No return-path models
>         Poor receiver modeling
>         No coupled parasitics
>         No coupled drivers (e.g. Open-drain current-mode differential)
>         No present method to model source modulation (gate starvation)
>
> The trouble is, the very things that IBIS doesn't do well (e.g. return
> path modeling) are exactly the things that are turning out to be the
> limiting factors in newer systems (e.g. source-synchronous systems.)
>
> As several others have pointed out, a lot of this isn't so much a problem
> with IBIS _per_se_ as it is a matter of IBIS taking on a job which isn't
> fundamentally behavioral and where a structural interconnect model works
> quite well.  After all it's not as though manufacurers are worried about
> giving out metal-interconnect data that can be found by anyone with a
> DVM.  Which argues, to me, that we should quit trying to reinvent the wheel.
>
> 3)      Proposed future course
>         Use IBIS [Model] for drivers and receivers
>         Enhance IBIS as needed to model input behavior
>         Enhance IBIS as needed to model gate starvation
>         Use EDIF netlist to model on-chip return paths
>         Use connector syntax or netlist to model package parasitics
>
> I'm not religious about the EDIF part.  An extended SPICE format that
> allows distributed parasitics would be just fine by me; maybe we should
> provide for both in the same way that HDLs can be both behavioral and
> structural.  The main thing is that a netlist-like format is really
> necessary to define the return-path and coupling effects that are taking
> over our applications.
>
> Now the radical part to me is the question of whether the result will
> be IBIS-calling-other-formats or other-formats-calling-IBIS.  From
> a heirarchical point of view, IBIS is at the lowest level of detail
> and you get all kinds of inversions trying to do it any other way.
> If there isn't presently some appropriate system-interconnect language
> that still doesn't mean that we should somehow make IBIS extend to both
> ends of the scale; it means that an appropriate top-level language needs
> to be created.  IBIS -- whatever it becomes -- stays at the bottom of
> the abstraction stack.
>
> Decoupling the need for a system-interconnect language from IBIS per se
> allows us to solve the problem without burdening the effort with the
> addition of another, perhaps nonbeneficial, constraint.  The connector
> group seems to have done just that with good results.
>
> --
> D. C. Sessions
> dc.sessions@vlsi.com

From owner-ibis  Mon Dec  6 03:07:52 1999
Received: from web2105.mail.yahoo.com (web2105.mail.yahoo.com [128.11.68.249]) by server.eda.org (8.8.5/8.8.3) with SMTP id DAA11605 for <ibis@eda.org>; Mon, 6 Dec 1999 03:07:51 -0800 (PST)
Received: (qmail 7976 invoked by uid 60001); 6 Dec 1999 11:07:11 -0000
Message-ID: <19991206110711.7975.qmail@web2105.mail.yahoo.com>
Received: from [63.210.146.99] by web2105.mail.yahoo.com; Mon, 06 Dec 1999 03:07:11 PST
Date: Mon, 6 Dec 1999 03:07:11 -0800 (PST)
From: "C. Kumar" <kumarchi@yahoo.com>
Subject: Re: YAFI
To: Christopher Reid <chris_reid@mentorg.com>,
        "D. C. Sessions" <dc.sessions@vlsi.com>
Cc: IBIS Mailing list <ibis@eda.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


I cannot agree more with Christopher. Nobody needs to
reinvent the wheel. The extesnions or better agrees
standard extensions to Spice are not that numerous
either. Basically you need two agreed standard

1. Multi coupled lossy tlines

2. Controlled current source (table , equation driven
with provision for event triggering)

--- Christopher Reid <chris_reid@mentorg.com> wrote:
> Hello,
> 
> Mostly I agree with D.C.  A netlist type structure
> is the only
> sensible route forward; otherwise IBIS will be
> burdened with
> frequent changes to take account of the latest ideas
> of how
> to model these effects (which we are already seeing
> in the
> proposals to split up C_comp.)
> 
> I'll vote for an extended SPICE syntax because I
> think that
> is most natural for this problem.  We could make
> IBIS devices
> that already exist into subcircuits callable by this
> syntax,
> or we could redefine the current structures using
> the new
> syntax.  I don't agree that IBIS is at the bottom of
> the abstraction
> hierarchy because it already contains some fairly
> complicated
> constructions.  The bottom of the hierarchy is the
> IV curves,
> threshold detectors, etc.
> 
> Chris
> 
> "D. C. Sessions" wrote:
> 
> > Yet Another Future IBIS
> >
> > I've been looking at this from the point of
> enumerating IBIS' strengths
> > and weaknesses.  As follows:
> >
> > 1)      IBIS strengths
> >         Good at simulation of classical CMOS
> drivers
> >         Adequate for TTL receivers
> >         OK for passing device pinouts
> >         OK for uncoupled package parasitics
> >         OK for selectable drive strength
> > 2)      IBIS weaknesses
> >         No return-path models
> >         Poor receiver modeling
> >         No coupled parasitics
> >         No coupled drivers (e.g. Open-drain
> current-mode differential)
> >         No present method to model source
> modulation (gate starvation)
> >
> > The trouble is, the very things that IBIS doesn't
> do well (e.g. return
> > path modeling) are exactly the things that are
> turning out to be the
> > limiting factors in newer systems (e.g.
> source-synchronous systems.)
> >
> > As several others have pointed out, a lot of this
> isn't so much a problem
> > with IBIS _per_se_ as it is a matter of IBIS
> taking on a job which isn't
> > fundamentally behavioral and where a structural
> interconnect model works
> > quite well.  After all it's not as though
> manufacurers are worried about
> > giving out metal-interconnect data that can be
> found by anyone with a
> > DVM.  Which argues, to me, that we should quit
> trying to reinvent the wheel.
> >
> > 3)      Proposed future course
> >         Use IBIS [Model] for drivers and receivers
> >         Enhance IBIS as needed to model input
> behavior
> >         Enhance IBIS as needed to model gate
> starvation
> >         Use EDIF netlist to model on-chip return
> paths
> >         Use connector syntax or netlist to model
> package parasitics
> >
> > I'm not religious about the EDIF part.  An
> extended SPICE format that
> > allows distributed parasitics would be just fine
> by me; maybe we should
> > provide for both in the same way that HDLs can be
> both behavioral and
> > structural.  The main thing is that a netlist-like
> format is really
> > necessary to define the return-path and coupling
> effects that are taking
> > over our applications.
> >
> > Now the radical part to me is the question of
> whether the result will
> > be IBIS-calling-other-formats or
> other-formats-calling-IBIS.  From
> > a heirarchical point of view, IBIS is at the
> lowest level of detail
> > and you get all kinds of inversions trying to do
> it any other way.
> > If there isn't presently some appropriate
> system-interconnect language
> > that still doesn't mean that we should somehow
> make IBIS extend to both
> > ends of the scale; it means that an appropriate
> top-level language needs
> > to be created.  IBIS -- whatever it becomes --
> stays at the bottom of
> > the abstraction stack.
> >
> > Decoupling the need for a system-interconnect
> language from IBIS per se
> > allows us to solve the problem without burdening
> the effort with the
> > addition of another, perhaps nonbeneficial,
> constraint.  The connector
> > group seems to have done just that with good
> results.
> >
> > --
> > D. C. Sessions
> > dc.sessions@vlsi.com
> 
> 

__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one place.
Yahoo! Shopping: http://shopping.yahoo.com
From owner-ibis  Tue Dec  7 09:32:40 1999
Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA21552 for <ibis@eda.org>; Tue, 7 Dec 1999 09:32:39 -0800 (PST)
Received: from mailhost.viewlogic.com (mailhost.viewlogic.com [139.181.3.35])
	by intermailhost.viewlogic.com (8.8.8/8.8.7) with ESMTP id MAA05793
	for <ibis@eda.org>; Tue, 7 Dec 1999 12:31:17 -0500 (EST)
Received: from taurus.camarillo.viewlogic.com (taurus.camarillo.viewlogic.com [139.181.194.20])
	by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id MAA23386
	for <ibis@eda.org>; Tue, 7 Dec 1999 12:31:16 -0500 (EST)
Received: from f22.viewlogic.com (f22.camarillo.viewlogic.com [139.181.194.48])
	by taurus.camarillo.viewlogic.com (8.9.3/8.9.3) with SMTP id JAA26003
	for <ibis@eda.org>; Tue, 7 Dec 1999 09:31:39 -0800 (PST)
Date: Tue, 7 Dec 1999 09:31:39 -0800 (PST)
From: Guy de Burgh <guy@camarillo.viewlogic.com>
Message-Id: <199912071731.JAA26003@taurus.camarillo.viewlogic.com>
To: ibis@eda.org
Subject: EIA IBIS Open Forum Meeting Minutes 12/3/99


DATE: 12/7/99

SUBJECT: 12/3/99 EIA IBIS Open Forum Meeting Minutes

VOTING MEMBERS AND 1999 PARTICIPANTS LIST:
Applied Simulation Technology  Raj Raghuram*, Norio Matsui, Neven Orhanovic,
                               Fred Ballesteri
Avanti                         Nikolai Bannov
Cadence Design                 Mike LaBonte*, Todd Westerhoff
Cisco Systems                  Syed Huq*
Compaq                         Bob Haller*, Steve Coe, Shafir Rahman,
                               Maher Elasad, Peter LaFlamme, Doug Burns
Cypress                        (Rajesh Manapat)
EMC Corporation                Fabrizio Zanella, Alex Nosovitski, Shan Haq
Fairchild Semiconductor        [Peter LaFlamme], Craig Klem, Graham Connolly,
                               Christian Klein*
H.A.S. Electronics             (Haruny Said)
Hewlett Packard (EEsof, etc.)  Paul Gregory, Henry Wu
HyperLynx (& Pads Software)    Matthew Flora*, Kellee Crisafulli, Lynne Green,
                               John Angulo*, Gene Garat, Robin Edwards
IBM                            Greg Edlund*, Michael Cohen*, Praven Patel,
                               Paul Clouser
Incases                        Olaf Rethmeier, Werner Rissiek, David Eagles,
                               Wilhelm Arnoldi, Ulrich Losch
Intel Corporation              Stephen Peters*, Arpad Muranyi*, Frank Kern,
                               Martin Chang, Dave Moxley, Kerry Nelson,
                               Jeff Day, Richard Mellitz, Peter Liou,
                               Will Hobbs, Henri Maramis
LSI Logic (Symbios Logic)      Scott King
Mentor Graphics                Bob Ross*, Mohamed Mahmoud, Sherif Hammad,
                               Jean Oudinot, Markku Kukkanen, Martin Groeber,
                               Karine Loudet, Hisham Gamal, Evgeny Wasserman,  
                               Tom Dagostino, Mohamed Nasef
Mitsubishi                     (Tam Cao)
Motorola                       Ron Werner*
National Semiconductor         Milt Schwartz*
North East Systems Associates  Edward Sayre, Michael Baxter, Kathy Breda,
                               Ed Sayre III, Jinhua Chen
NEC                            (Hiroshi Matsumoto)
Nortel Networks                Martin Hall (& at Viewlogic), Calvin Trowell*
                               Ross Pryor
Philips Semiconductor          Todd Andersen, Peter Christiaans
Quantic EMC                    (Mike Ventham)
Siemens                        Bernhard Unger, Christian Mitschke, 
                               Manfred Maurer, Peter Kaiser, Wolfram Meyer,
                               Gerald Bannert, Harmut Ibowski, Katja Zuleeg,
                               Hans Pichlmaier, Eckhard Lenski, Kortheuer Udo,
                               Christian Sporrer
SiQual                         Scott McMorrow
Texas Instruments              Jean-Claude Perrin, Shankar Balasubramaniah,
                               Ramzi Ammar, Thomas Fisher
3Com                           Roy Leventhal*
Time Domain Analysis Systems   Dima Smolyansky, Steven Corey
Viewlogic Systems              Chris Rokusek, Guy de Burgh*, Cary Mandel,
                               (Jon Powell)
VeriBest                       [Ian Dodd]
Via Technologies               (Weber Chuang)
VLSI Technology                D.C. Sessions

OTHER PARTICIPANTS IN 1999:
3Dfx Interactive               Ken Wu
Actel Corporation              Silvia Montoya
Alcatel                        Steven Criel
Analytical Edge                Robert Easson
Applied Microelectronics       Brian Sanderson
BMW                            Friedrich Haslinger
Bogatin Enterprise             Eric Bogatin
Bosch Telecom                  Detlef Wolf
Celestica                      Danny Da Silva
Dynamics Research Corporation  Mike Walsh
ECI Telecom                    Daniel Adar
EIA                            [Patti Rusher], Cecilia Fleming,
                               Dan Heinemeier 
Electronique                   Catherine Gross
EFM Consulting                 Ekkehard Miersch
FCI                            John Ellis
Foxcomm                        Jeff Walden
General DataComm               Laurence Michaels
High Design Technology         Razvan Ene
Hitachi ULSI                   Hideki Fukuda
Infineon                       Thomas Latzel
Intracon Design                Mike Osmond
KAW                            Shinichi Maeda
Litton Systems                 Robert Bremer
Lucent                         Jason Pritchard
Matsushita                     Atsuji Itoh
Molex Incorporated             Gus Panella*
Newbridge Networks             Bruce Carlile
Oce Printing Systems           Ernst Deiringer
Praegitzer Design              Rick Newell, Paul Galloway, Joe Socha
Rockwell Collins               Susan Tweeton, Ron Hau
Rode Consulting                Chris Rode
Samsung                        Jung-Gun Byun, Cheol-Seung Choi
Shindengen                     Tsuyoshi Horigome
Signals & Systems Engineering  Tom Hawkins
STMicroelectronics             Fabrice Boissieres, Philippe LeFevre
Stratus                        Keith Vieira
StorageTek                     Nick Krull
Sun Microsystems               Victor Chang Kevin Ko, Greg Fitzgerald,
                               Nick LaPlaca
Tektronix                      Tom Brinkoetter
Teradyne                       Mikhail Khusid
VDOL                           Robert Novosel
Xilinx                         Susan Wu
(Unaffiliated, Retired)        Bruce Wenniger


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

Upcoming Meetings:  The bridge numbers for future IBIS teleconferences are as
follows:
  
  Date                Bridge Number    Reservation #    Passcode
  December 17, 1999   (916) 356-9200   2-368942         8917482

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

NOTE: "AR" = Action Required.

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

INTRODUCTIONS AND MEETING QUORUM
Bob Ross started the meeting and stated that there were the required number
of companies present to establish a quorum.
Bob Ross and Stephen Peters conducted the meeting.


MEMBERSHIP UPDATE AND TREASURER'S REPORT
Dues Statements to be sent out in mid Dec.  Several companies joined late and will
be billed just the difference for year 2000.  

Another company is joining.  We are waiting the receipt of the purchase
order before officially announcing the company.


REVIEW OF MINUTES AND AR'S
The November 11, 1999 IBIS Open Forum Meeting minutes were approved without
change.

The AR's will be discussed during the meeting.


MISCELLANY/ANNOUNCEMENTS
None.


PRESS AND WEB PAGE UPDATES
Syed Huq has updated the roster for Nortel and, the Siemens URL and the link to
the IMIC document.


NEW MODELS AVAILABLE, LIBRARY UPDATE
Jon Powell uploaded a new Model Page and put in links to the company home site
and also to models.  Jon discovered a changed link for Infineon Technologies:

  http://www.infineon.com/products/memory/appl/models/3177.htm

Send comments and new links to Jon.  He will do another update over Christmas
vacation.


OPENS FOR NEW ISSUES
None


INTERNATIONAL/EXTERNAL PROGRESS
- IEC 62014-1 (IBIS Version 3.2) - Bob Ross had no further progress report
from Cecilia Fleming.  However formal ratification of IBIS Version 3.2 as
IEC 62104-1 is still expect shortly (a month or less).

- pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits
(IMIC) - Bob Ross had no further report and repeated from last meeting that a
Version 1.2 has been posted for review with a deadline of December 25, 1999.
Note added after the meeting: the link to the document has been moved and is
now located at the bottom of:

  http://tsc.eiaj.or.jp/eds/iopg.htm

- IEC PWI 93-1 Models of Integrated Circuits for EMI Behavioral Simulation
(formerly designated as IEC 93/67/NP IBIS and EMC Simulation) - Bob Ross
had no report.

- JC-16.2 Subcommittee: Modeling and Test - Bob Ross had no report.


DESIGNCON 2000 IBIS SUMMIT PLANNING
Bob Ross reported that Jon Powell sent out a request for Member Companies to
to provide an 8-1/2 by 11 inch logo on a hard board (foam) for display at the
IBIS booth.  There is a possibility that Bob Haller will arrange a new accuracy
demonstration for the booth.

Bob Ross and Milt Schwartz are preparing the initial announcement to be
sent out in early to mid December.

Bob Ross stated that the IBIS Summit meeting is being held on Monday,
January 31, 2000 in Santa Clara, California.  The IBIS Open Forum is listed 
again as an Associate Sponsor of DesignCon 2000 which means that DesignCon
is providing the meeting room and refreshments and also booth space.

Milt Schwartz offered that National Semiconductor is sponsoring again the
buffet luncheon.  He also stated that presenters may send him electronic
copies, and National Semiconductor will make copies available at the meeting.

Bob indicated that Jon Powell will be providing the booth and coordinating
the setup.  He plans again to have IBIS Open Forum member company
logos posted on the backdrop.  It will be a place to meet, pick up literature,
and possibly host an electronic accuracy demonstration.

Bob stated plans that we will be sending out the first notice in early
December.  We do have several presentations and will plan on some extended
discussions on some of the new topics that are now being considered.


DATE2000 IBIS SUMMIT PLANNING
Bob Ross commented that the DATE2000 IBIS Summit meeting associated with the
Design Automation and Testing in Europe conference is still planned to be
held in Paris, France on Friday, March 31, 2000. The meeting will end early in
the afternoon to allow attendees to fly back that evening.  Mentor
Graphics and Incases are co-sponsors, but others are expected.  The PCB
Symposium is scheduled for Thursday, March 30, 2000.


COOKBOOK STATUS
Stephen Peters had no report.


IBIS MODEL REVIEW COMMITTEE DISCUSSION
No new models.


S2IBIS3 PROPOSAL DISCUSSION

Bob Ross raised the issue of whether IBIS should fund projects that
conflict with commercial projects.

S2IBIS3 COMMITTEE REPORT
Michael Cohen gave a short history of the committee. They have had several
meetings and have produced a document for review.
The document resides in the IBIS Home Page under s2ibis3 Project:

  http://www.eia.org/eig/ibis/ibis.htm

or directly from

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

A note was sent to the IBIS and SI relectors inviting reviews of the document.
Mike Cohen noted that there were no real value responses except from one person.
Bob Ross drafted a cover letter for potential bidders. Mike Cohen will
review it and send to the committee next week.

Bob Ross noted that we are now at the next step. One of the options is to stop
here. The other option, which is the committee's intention, is to see if anyone
wants to build a S2IBIS3 product that conforms to the document.

Bob Ross added that, for a number of years, we have had Spice to IBIS 2 from
North Carolina that was created under a Darpa contract. This was then turned
over to the IBIS committee.

Bob Ross continued that before we send out the bid we should decide whether or
not to go forward.  The issue is that we do have one commercial product that
deals with Spice to IBIS conversion. It is not a free product like the North
Carolina, but is a better product.

The product in question is from Applied Simulation Technology. It is a public
product. Furthermore Applied Simulation Technology are a voting member of the
IBIS committee. Bob Ross noted that this project would conflict with a commercial
interest.

Bob Ross then asked if anyone has any arguments in favor of requesting bids
to fund the S2IBIS3 project.

Mike Cohen said that he does not see this product conflicting with the currently
existing commercial product. Mike said there are reasons to have both, and it
gives the smaller companies a tool to generate IBIS without spending too much
money. Mike said that it is not a conflict because it furthers the IBIS spec.

Stephen Peters noted that we faced a similar situation with a parameter extraction
product from Tektronix. The IBIS committee at that time rejected that proposal,
thereby setting a precedent. Mike Cohen pointed out that there were differences
between that situation and this one.

Bob Ross gave a history of S2IBIS2. The existing Spice to IBIS code
(originally from North Carolina) is freeware, and served its purpose of helping
to develop IBIS models. It has been used as a seed for companies to modify for
their own flavor of Spice. It was never intended to be a commercial product. It
was never of commercial quality. Bob noted that IBIS has been in this arena for
a long time, and should maintain and upgrade the product to support the latest
IBIS specification.

Syed Huq noted that there were no commercial alternatives to S2IBIS and S2IBIS2
when these programs were developed. This shareware is being used by the majority
of the model developed developers. The proposal, S2IBIS3, is really bug fixing
and extending it to IBIS version 3. Commercial solutions are always welcome, but
it is up to the user community to decide whether they want commercially available
software or freeware from the IBIS forum. Syed continued that this is a logical
progression of things that we have been doing for a long time and gave, as an
example, that the free Berkeley Spice has not prevented the success of commercial
Spice programs.

Ron Werner noted that shareware shows proof of concept, and companies can use
it and expand on it. He further noted that given that amount of time and the
number of people that are using S2IBIS2 that he is not too excited about putting
out bids and paying somebody to upgrade the product that is there.

Arpad Muranyi noted that S2IBIS has some issues, and a commercial product has
better quality. The plan is make S2IBIS2 more user friendly and fix the bugs.
Arpad expressed concern as to how much money the IBIS forum can put into S2IBIS3.

Roy Leventhal asked if by having a piece of shareware for free will that
prevent commercial vendors taking it, improving it, and selling it, and does the
lack of the shareware have an impact on the adoption of IBIS.

Bob Ross noted that the lack of shareware has not affected the adoption
of IBIS. He also noted that the freeware does not prevent commercial vendors
from making their own improvements.

Roy Leventhal mentioned that he has trouble getting IBIS models and that the lack
of a S2IBIS converter doesn't seem to affect that.

Stephen Peters mentioned that the presence or lack of a S2IBIS converter does
not affect the availability of models, but the issue is the quality of the
models from the S2IBIS converter.

Bob Ross noted that if it was the intent of the IBIS committee to sell this product
then we do not have any business being in this arena. IBIS is a public consortium
generating public standards and offering free tools. It is not in the business of
creating a commercially available product. 

Syed Huq noted that one of the enablers for vendors to create IBIS models is the
S2IBIS tool. S2IBIS3 will be an enabler to further generate more models.

Bob Ross noted that we have an obligation to maintain the current S2IBIS tool.
Withdrawing it is not a option.

Ron Werner suggested that there should be some enticement for commercial people
to improve S2IBIS.

Matt Flora wanted to hear a discussion of what we think would be the result of
not funding an S2IBIS3 and wanted to know if we would be having this debate if
no commercial product currently existed.

Fred Ballesteri noted that IBIS actively promotes S2IBIS, unlike Berkeley which
does not promote Spice. This active promotion is stifling commercial vendors
from producing their own. He noted that it is not fair to take ideas from his
company's product and exploit them by implementing them in S2IBIS3. S2IBIS3, a free
product, is in competition with commercial products. He noted that, in his view, that
S2IBIS has done more to hurt IBIS than help it. He further noted that IBIS is in
this predicament because IBIS has been promoting a tool that does not reflect the
current state of IBIS.

Bob Ross noted that the IBIS committee has been very supportive of commercial
entries. He suggested that this be put to a formal vote at the next meeting.


CONNECTOR PROPOSAL REVIEW 

Bob Ross gave an overview of the specification.  He mentioned the links on the
Web to the spec and the samples.  The spec. is going to be considered as a
separate document and is intended to describe connectors only and currently
only lossless connectors.  There is a lot of similarity with IBIS but a lot of
differences as well.
 
Gus Panella pointed out that the uploaded samples were generated under the
original spec proposal (0.31) and may have some minor deviation from the 0.92
spec.

CONNECTOR PROPOSAL

Arpad Murani suggested that we should set a goal in setting a time for
resolution of this proposal, and whether this proposal should be standalone
or part of the IBIS spec.

Arpad noted that the connector spec is about two years late, and he would like
to be included as soon as possible.

Bob Ross noted that the document needs to be reviewed, discussed and voted on.
He mentioned that with this in mind the best target date would be Q1/2000,
and this is an estimate.

Gus Panella noted, along with Bob Ross, that a separate spec. is the quickest way to
go, initially. It could be incorporated later. Gus noted that both he and Kellee
Chrisafulli encourage reflector discussion.

The latest documents are available from the EIA IBIS Home page
and:

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

Gus clarified that this is a lossless model, but a lossy model could be made
using the cascaded multiline matrix. A frequency dependent matrix will be 
included later.

Stephen Peters and Gus Panella clarified how the lossy model could be
implemented.

Stephen Peters mentioned that Bob Ross wanted a review committee to take a look
at the spec.  Stephen asked for volunteers.

Matthew Flora asked what the reaction of the connector vendors to the spec. has 
been. Gus Panella responded that a number of companies have reviewed it, and that
it conforms to their modeling process fairly well.

Matthew Flora mentioned that Bob Ross had a good idea of trying to create models
for real connectors rather than contrived connectors.
Gus Panella discussed the examples and verification process. He outlined the
method of taking a real connector and making a model out of it.

Matthew Flora asked once the spec. is ratified how quickly will models become
available. Gus Panella responded that Molex is making models.

Stephen Peters asked how simulator companies will respond to this spec.
Matthew Flora said he assumed HyperLynx would since they were so involved in the spec.
 
Raj Raghuram felt it would not be very difficult to add.
 
Gus Panella pointed out that the inductance handling might be a little bit different
from current implementations.  He said that he feels support will be more of a
simulator issue than a model building issue.
 
Raj Raghuram suggested that the capacitance matrices may be harder to implement that
the inductances.

Stephen Peters encouraged everyone to review the spec.


NEXT MEETING:
The next teleconference meeting will be on Friday, December 17, 1999 from
8:00 AM to 10:00 AM.


Stephen Peters closed the meeting.

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

IBIS CHAIR: Bob Ross (503) 685-0732, Fax (503) 685-4897
            bob_ross@mentor.com
            Modeling Engineer, Mentor Graphics
            8005 S.W. Boeckman Road, Wilsonville, OR 97070

VICE CHAIR: Stephen Peters (503) 264-4108, Fax: (503) 264-4515
            sjpeters@ichips.intel.com
            Senior Hardware Engineer, Intel Corporation
            M/S JF1-209
            2111 NE 25th Ave. 
            Hillsboro, OR 97124-5961

SECRETARY:  Guy de Burgh (805) 988-8250, Fax: (805) 988-8259
            gdeburgh@viewlogic.com
            Senior Manager, Viewlogic Systems
            1369 Del Norte Rd.
            Camarillo, CA 93010-8437

LIBRARIAN:  Jon Powell (805) 988-8250, Fax: (805) 988-8259
            jpowell@viewlogic.com
            Senior Scientist, Viewlogic Systems
            1369 Del Norte Rd.
            Camarillo, CA 93010

WEBMASTER:  Syed Huq (408) 525-3399, Fax: (408) 526-5504
            shuq@cisco.com
            Signal Integrity Engineer, Cisco Systems
            170 West Tasman Drive
            San Jose, CA 95134-1706

POSTMASTER: Matthew Flora (425) 869-2320, Fax: (425) 881-1008
            mbflora@hyperlynx.com
            Senior Engineer, HyperLynx, Inc.
            114715 N.E. 95th Street
            Redmond, WA 98052
 
This meeting was conducted in accordance with the EIA Legal Guides and EIA
Manual of Organization and Procedure.

The following e-mail addresses are used:

  ibis-request@eda.org
      To join, change, or drop from either the IBIS Open Forum Reflector
      (ibis@eda.org), the IBIS Users' Group Reflector (ibis-users@eda.org)
      or both.  State your request.

  ibis-info@eda.org
      To obtain general information about IBIS, to ask specific questions
      for individual response, and to inquire about joining the EIA-IBIS
      Open Forum as a full Member.

  ibis@eda.org
      To send a message to the general IBIS Open Forum Reflector.  This
      is used mostly for IBIS Standardization business and future IBIS
      technical enhancements.  Job posting information is not permitted.

  ibis-users@eda.org
      To send a message to the IBIS Users' Group Reflector.  This is 
      used mostly for IBIS clarification, current modeling issues, and
      general user concerns.  Job posting information is not permitted.

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

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

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

  http://www.eia.org/eig/ibis/ibis.htm

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

From owner-ibis  Wed Dec  8 12:42:36 1999
Received: from natsemi3-bh.nsc.com (natsemi3-bh.nsc.com [205.227.60.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA00805 for <ibis@eda.org>; Wed, 8 Dec 1999 12:42:36 -0800 (PST)
Received: (from uucp@localhost) by natsemi3-bh.nsc.com (8.8.8/8.6.11) id PAA16475 for <ibis@eda.org>; Wed, 8 Dec 1999 15:41:45 -0500 (EST)
Received: from scmh1.nsc.com(139.187.179.130) by natsemi3-bh.nsc.com via smap (4.1)
	id xmaqb1013; Wed, 8 Dec 99 15:39:22 -0500
Received: from scmh1-gw.nsc.com by scmh1.nsc.com (X.400 to RFC822 Gateway); Wed, 8 Dec 1999 12:34:56 -0800
X400-Received: by mta MTANSC1 in /c=us/admd= /prmd=National/; Relayed; 
  08 Dec 1999 12:32:13 -0800
X400-Received: by /c=us/admd= /prmd=National/; Relayed; 
  08 Dec 1999 12:32:13 -0800
X400-MTS-Identifier: [/c=us/admd= /prmd=National/; 09C24384EC04D0C6-MTANSC1]
Content-Identifier: 09C24384EC04D0C6
Content-Return: Allowed
X400-Content-Type: P2-1988 ( 22 )
Conversion: Allowed
Original-Encoded-Information-Types: IA5-Text
Priority: normal
Disclose-Recipients: Prohibited
Alternate-Recipient: Allowed
X400-Originator: Milt.Schwartz@nsc.com
X400-Recipients: non-disclosure;
Message-Id: <"09C24384EC04D0C6*/c=US/admd= /prmd=National/o=notes/ou=Americas/s=Schwartz/g=Milt/"@MHS>
Date: 08 Dec 1999 12:32:13 -0800
From: Milt Schwartz <Milt.Schwartz@nsc.com>
To: ibis <ibis@eda.org>
Subject: IBIS 2000; First Call

To All:

This is the first call for presentations and participation at the 
IBIS Summit Meeting held with DesignCon 2000.

Milt Schwartz
National Semiconductor



       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       ----------------------------------------------------------------
       DESIGNCON 2000 IBIS SUMMIT CALL FOR PARTICIPATION, PRESENTATIONS
       ----------------------------------------------------------------
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Time/Date:     8:00 PM - 5:00 PM, Monday, January 31, 2000

Location:      Santa Clara Convention Center
               Santa Clara, CA

Content:       IBIS Future Requirements is the main topic of this meeting
               These include an exchange of ideas on IBIS accuracy,
               connectors, and new requirements under discussion.

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

Sponsors:      DesignCon 2000 & National Semiconductor Corporation

IBIS Summit Signup:
               Milt Schwartz
               schwartz@nsc.com


                   D E S I G N C O N   2 0 0 0   M E E T I N G S

Time/Date:     Monday - Thursday, January 31 - February 3, 2000

Exhibition:    Tuesday - Wednesday, 12:30 PM - 6:30 PM, February 1 - 2, 2000

IBIS Booth:    #1039, Exhibition Hall
               - Possible Accuracy Committee Demonstration
               - IBIS Information
               - Contact Jon Powell, jpowell@viewlogic.com, for information.

URL DesignCon99:
               http://www.designcon.com/

Signup Discount:  
               IBIS member companies may receive a 15 percent discount to
               the DesignCon 2000 Conference.  Past Conference attendees
               also will receive a 20% alumni discount.


CALL FOR IBIS SUMMIT PRESENTATIONS

We already have several presentations and discussion topics planned.  However,
we are also seeking presentations from individuals who have IBIS experiences
or issues.

Format of Presentation:  Overhead Projections
Time:                    15-30 Minutes
Electronic Archival:     We request electronic versions so that the
                         presentations can be archived and also made
                         available to non-attendees.  Formats used in
                         the past have been text, Power Point, Word, 
                         Postscript, and Acrobat.  If you cannot provide
                         an electronic format, then plan to bring 50
                         copies for distribution at the meeting.


If you plan a presentation, please supply

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

  Estimate Time:

Send this to:

  Milt Schwartz
  schwartz@nsc.com

Deadline: Wednesday, January 26, 2000 for receiving presentations for
          copying.
 

AGENDA

The agenda includes presentations, discussions, refreshments, and a free
buffet luncheon for participants.  In addition, we will have an opportunity
for Ad Hoc presentations and extended discussions.



regards, milt
Milt Schwartz Interface Applications
National Semiconductor
email: schwartz@nsc.com
Phone: 408-721-3261
Fax:     408-721-4785
Mail Stop: A2595
From owner-ibis  Thu Dec  9 17:31:43 1999
Received: from dns.uei.co.jp (dns.uei.co.jp [210.160.168.194]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA09594; Thu, 9 Dec 1999 17:31:40 -0800 (PST)
Received: from duckcad ([192.168.100.33])
	by dns.uei.co.jp (8.8.8+2.7Wbeta7/3.6W) with SMTP id KAA24290;
	Fri, 10 Dec 1999 10:26:29 +0900 (JST)
Message-ID: <006301bf42af$7af79860$2164a8c0@uei.co.jp>
From: "THAM KOK TONG" <tham@uei.co.jp>
To: <ibis@eda.org>, <ibis-users@eda.org>
Subject: Rising Waveform
Date: Fri, 10 Dec 1999 10:40:03 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_005F_01BF42FA.EAC54FC0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

------=_NextPart_000_005F_01BF42FA.EAC54FC0
Content-Type: text/plain;
	charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit

Hello All,

Anybody can tell me what will happen to the output waveform
if my IBIS model which only contain a Rising Waveform for V_fixture=0.0v and
Falling Waveform for V_fixture=3.3v?
My output waveform disable to reach full amplitude(3.3V), is the Rising
Waveform is the main problem?

Reagrds,
KT.THAM


------=_NextPart_000_005F_01BF42FA.EAC54FC0
Content-Type: text/html;
	charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-2022-jp" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Hello All,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Anybody can tell me what will happen to</FONT><FONT =
size=3D2>=20
the output wavefor</FONT><FONT size=3D2>m</FONT></DIV>
<DIV><FONT size=3D2>if my IBIS model which only contain a Rising =
Waveform for=20
V_fixture=3D0.0v and Falling Waveform for V_fixture=3D3.3v?</FONT></DIV>
<DIV><FONT size=3D2>My output waveform disable to reach full =
amplitude(3.3V), is=20
the Rising Waveform is the main problem?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Reagrds,</FONT></DIV>
<DIV><FONT size=3D2>KT.THAM</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_005F_01BF42FA.EAC54FC0--

From owner-ibis  Mon Dec 13 13:46:17 1999
Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA01084 for <ibis@eda.org>; Mon, 13 Dec 1999 13:46:10 -0800 (PST)
Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id NAA11037; Mon, 13 Dec 1999 13:44:53 -0800 (PST)
Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R)
	id NAA16328; Mon, 13 Dec 1999 13:44:52 -0800 (PST)
Sender: bob_ross@mentorg.com
Message-ID: <385568D2.2E2D98E9@mentor.com>
Date: Mon, 13 Dec 1999 13:44:50 -0800
From: Bob Ross <bob_ross@mentorg.com>
X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: ibis@eda.org
Subject: IBIS Meeting 12/17/99
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


                     IBIS Open Forum Meeting Agenda 
                               for 12/17/99

                 Bridge Number    Reservation #   Passcode
                 (916) 356-9200   2-368942        8917482

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

8:00 Check-In, Intros, Announcements                         Ross

     - Intros of New IBIS Participants, Meeting Quorum       Ross
     - Membership Update and Treasurers Report               Ross/Fleming
     - Review of Previous Meeting's Minutes (and ARs)        Ross
     - Miscellany/Announcements                              All
     - Press & Web Page Updates                              Huq, All
     - New Models Available, Library Update                  Powell, All
     - Opens for New Issues                                  All

8:15 Administrative and Project Discussions

     International/External Progress
     - IEC 62014-1 (IBIS Version 3.2)                        Ross/Fleming
     - pr EIAJ ED-5302 Standard for I/O Interface Model      
          for Integrated Circuits (IMIC)                     Raghuram/Ross
     - IEC PWI 93-1 Models of Integrated Circuits for EMI 
       Behavioral Simulation (formerly designated as
       IEC 93/67/NP IBIS and EMC Simulation)                 Perrin
     - JEDEC JC-16.2 Modeling and Testing                    Sessions

     DesignCon2000 IBIS Summit Planning                      Ross/Schwartz
    
     DATE2000 IBIS Summit Planning                           Ross

     Cookbook Status                                         Peters

     IBIS Model Review Committee                             Flora

     S2ibis3 Proposal Discussion (Vote?)                     Cohen

     New Administrative Issues                               All

8:45 Technical Discussion (some topics may be deferred)

     Connector Proposal Review (Continued)              Panella/Chrisafulli

     IBIS Futures (IBIS-X, API, BIRDxx)                      Peters/Muranyi

     BIRD64 - Package Model Selector                         Muranyi

     BIRD66 - [Model Spec] Vref Addition                     McMorrow/Ross

     BUG34 - No Error Reported for Missing V/I Tables        Flora
             in Output Buffers

     BIRD61 - Enhanced Characterization of Receivers         Peters

     BIRD62 - Enhanced Chararcterization of Receiver         Peters
              Thresholds

     BIRD63 - Documentation of Receiver Setup and Hold       Peters
              Timing Conditions

     BIRD65 - C_comp Refinements                             Muranyi

     New Technical Issues                                    All

9:50 Wrap Up and Next Meetings Plans                         Peters

9:55 Sign Off
From owner-ibis  Thu Dec 16 05:49:54 1999
Received: from molexinc-bh.molex.com (molexinc-bh.molex.com [204.167.149.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id FAA28414 for <ibis@eda.org>; Thu, 16 Dec 1999 05:49:53 -0800 (PST)
From: apanella@molex.com
Received: (from uucp@localhost) by molexinc-bh.molex.com (8.8.8/8.6.11) id HAA20368 for <ibis@eda.org>; Thu, 16 Dec 1999 07:49:07 -0600 (CST)
Received: from smtp2.molex.com(150.150.15.101) by molexinc-bh.molex.com via smap (4.1)
	id xma020251; Thu, 16 Dec 99 07:48:12 -0600
Received: from ccMail by smtp2.molex.com
  (IMA Internet Exchange 3.0 Enterprise) id 000ACA70; Thu, 16 Dec 99 07:45:02 +0000
Mime-Version: 1.0
Date: Thu, 16 Dec 1999 07:43:34 +0000
Message-ID: <000ACA70.CE21031@molex.com>
Subject: RE: IBIS Meeting 12/17/99
To: Bob Ross <bob_ross@mentorg.com>, ibis@eda.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

Bob / Kellee,

I have a prior meeting commitment starting at 10:00 on Dec. 17

Therefore, I unfortunately will not be able to attend the meeting...  Kellee,
would you be able to attend??

However,  I have not seen ANY  comments (zero, nada, zilch, nothing, etc.) on
the reflector with regards to the IBIS connector specification.  So, is there
really anything to talk about? From the lack of response.. either everyone
thinks it's great... or everyone hasn't read it...  Maybe... if we can use the
meeting to URGENTLY request more (some?) feedback!!

Either way... it would be nice to get feedback and question with regards to the
specification before we get into an open phone discussion, such that there would
be time to prepare concise answers or create a change to the specification...

Best Regards,
_gus


> -----Original Message-----
> From: Bob Ross <bob_ross@mentorg.com> 
> Sent: Monday, December 13, 1999 1:45 PM
> To: ibis@eda.org
> Subject: IBIS Meeting 12/17/99
> 
> 
> 
>                      IBIS Open Forum Meeting Agenda 
>                                for 12/17/99
> 
>                  Bridge Number    Reservation #   Passcode
>                  (916) 356-9200   2-368942        8917482
>
 <SNIP> 
From owner-ibis  Thu Dec 16 15:51:46 1999
Received: from calliope1.fm.intel.com (calliope1.fm.intel.com [132.233.247.10]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA00492 for <ibis@eda.org>; Thu, 16 Dec 1999 15:51:45 -0800 (PST)
Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202])
	by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.10 1999/10/20 18:19:05 spurcell Exp $) with SMTP id PAA06689
	for <ibis@eda.org>; Thu, 16 Dec 1999 15:50:29 -0800 (PST)
Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Thu, 16 Dec 1999 23:50:19 0000 (GMT)
Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2448.0)
	id <Y3NAX309>; Thu, 16 Dec 1999 15:50:18 -0800
Message-ID: <4575832C8E71D111AC4100A0C96B512704A79B50@fmsmsx36.fm.intel.com>
From: "Muranyi, Arpad" <arpad.muranyi@intel.com>
To: ibis@eda.org
Subject: RE: IBIS Meeting 12/17/99
Date: Thu, 16 Dec 1999 15:50:16 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"

I was supposed to write this a long time ago, but things are crazy
around here lately so I couldn't.  Not that I have more time now,
but this is for the cause.

I noticed that most keywords have a description in the usage rules for
where they can appear in a model.  However, a few do not mention anything.
It would be nice to consistently explain this for every single keyword.
The ones I couldn't find this description for are:
  [Begin/end_Cn_Model_List],
  [Begin/end_Cn_Model],
  [Row],
  [Diagonal_matrix],
  [Banded_matrix],
  [Sparce_matrix],
  [Bandwidth]

A keyword tree, or map would be a good aid in determining the hierarchical
ordering and dependencies of the keywords.

Also, since the words are usually capitalized in these keywords, the word
"matrix" should be also spelled with a capitol "M".  The square brackets
"[" and "]" are missing from some of these keywords also.

In the units section it only goes from Tera to fempto.  Since coupling
can be very small, we should extend this (at least) on the low side ("a" for
anno 1e-18, etc).

I wonder about the rules of required matrixes (L, C, and R).  I understand
the
cases listed in the spec, but I wonder about unexpected usage.  For example,
I was looking into using this spec for on-die interconnect descriptions.  If
I
succeeded with that, I may need to provide an RC type interconnect, not LC.
According to the requirements of this spec this would not be possible.

Other than that, I think it is a very good spec.  Thanks for all the work
that went into it.

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



-----Original Message-----
From: apanella@molex.com [mailto:apanella@molex.com]
Sent: Thursday, December 16, 1999 5:44 AM
To: Bob Ross; ibis@eda.org
Subject: RE: IBIS Meeting 12/17/99


Bob / Kellee,

I have a prior meeting commitment starting at 10:00 on Dec. 17

Therefore, I unfortunately will not be able to attend the meeting...
Kellee,
would you be able to attend??

However,  I have not seen ANY  comments (zero, nada, zilch, nothing, etc.)
on
the reflector with regards to the IBIS connector specification.  So, is
there
really anything to talk about? From the lack of response.. either everyone
thinks it's great... or everyone hasn't read it...  Maybe... if we can use
the
meeting to URGENTLY request more (some?) feedback!!

Either way... it would be nice to get feedback and question with regards to
the
specification before we get into an open phone discussion, such that there
would
be time to prepare concise answers or create a change to the
specification...

Best Regards,
_gus


> -----Original Message-----
> From: Bob Ross <bob_ross@mentorg.com> 
> Sent: Monday, December 13, 1999 1:45 PM
> To: ibis@eda.org
> Subject: IBIS Meeting 12/17/99
> 
> 
> 
>                      IBIS Open Forum Meeting Agenda 
>                                for 12/17/99
> 
>                  Bridge Number    Reservation #   Passcode
>                  (916) 356-9200   2-368942        8917482
>
 <SNIP> 

From owner-ibis  Fri Dec 17 07:54:42 1999
Received: from molexinc-bh.molex.com (molexinc-bh.molex.com [204.167.149.66]) by server.eda.org (8.8.5/8.8.3) with ESMTP id HAA07453 for <ibis@eda.org>; Fri, 17 Dec 1999 07:54:41 -0800 (PST)
From: apanella@molex.com
Received: (from uucp@localhost) by molexinc-bh.molex.com (8.8.8/8.6.11) id JAA08214 for <ibis@eda.org>; Fri, 17 Dec 1999 09:53:55 -0600 (CST)
Received: from smtp2.molex.com(150.150.15.101) by molexinc-bh.molex.com via smap (4.1)
	id xma008030; Fri, 17 Dec 99 09:53:23 -0600
Received: from ccMail by smtp2.molex.com
  (IMA Internet Exchange 3.0 Enterprise) id 000AECAC; Fri, 17 Dec 99 09:50:10 +0000
Mime-Version: 1.0
Date: Fri, 17 Dec 1999 09:49:33 +0000
Message-ID: <000AECAC.CE21031@molex.com>
Subject: RE: IBIS Meeting 12/17/99
To: Arpad" <arpad.muranyi@intel.com>, ibis@eda.org"@molexinc-bh.molex.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part

Arpad.

THANK-YOU for the comments...

For what it is worth, A couple of the keywords that are not defined in IBISCnn
are common to the general IBIS spec..  As such, the definitions are the same. 
However, I would agree that if this is a standalone document that the
definitions should most likely be included.

For the non-standard keyword definitions...  Good Eyes!!  We will definitely
need to add these!

I also like the idea of a keyword tree.  I think that this  would be a good
supporting document.

Another idea that I have been playing with is a keyword database file.  This way
we could search any field (keyword, description, syntax, other) and display
usage.  However, this may be beyond the scope.  I am not sure..  Comments?

Re: anno
Is it anno  or atto?

Re: "RC"
This, not spelled out....  but for what it is worth.... it is possible to use a
RLC matrix.. then set all the L values to "0"...  Same effect but clumsy...  I
think that the addition of RC would be good.


_gus

> -----Original Message-----
> From: "Muranyi; Arpad" <arpad.muranyi@intel.com> 
> Sent: Thursday, December 16, 1999 3:50 PM
> To: ibis@eda.org
> Subject: RE: IBIS Meeting 12/17/99
> 
> 
> I was supposed to write this a long time ago, but things are crazy
> around here lately so I couldn't.  Not that I have more time now,
> but this is for the cause.
> 
> I noticed that most keywords have a description in the usage rules for
> where they can appear in a model.  However, a few do not 
> mention anything.
> It would be nice to consistently explain this for every 
> single keyword.
> The ones I couldn't find this description for are:
>   [Begin/end_Cn_Model_List],
>   [Begin/end_Cn_Model],
>   [Row],
>   [Diagonal_matrix],
>   [Banded_matrix],
>   [Sparce_matrix],
>   [Bandwidth]
> 
> A keyword tree, or map would be a good aid in determining the 
> hierarchical
> ordering and dependencies of the keywords.
> 
> Also, since the words are usually capitalized in these 
> keywords, the word
> "matrix" should be also spelled with a capitol "M".  The 
> square brackets
> "[" and "]" are missing from some of these keywords also.
> 
> In the units section it only goes from Tera to fempto.  Since coupling
> can be very small, we should extend this (at least) on the 
> low side ("a" for
> anno 1e-18, etc).
> 
> I wonder about the rules of required matrixes (L, C, and R).  
> I understand
> the
> cases listed in the spec, but I wonder about unexpected 
> usage.  For example,
> I was looking into using this spec for on-die interconnect 
> descriptions.  If
> I
> succeeded with that, I may need to provide an RC type 
> interconnect, not LC.
> According to the requirements of this spec this would not be possible.
> 
> Other than that, I think it is a very good spec.  Thanks for 
> all the work
> that went into it.
> 
> Arpad
> ==============================================================
> ===========
> 
> 
> 
> -----Original Message-----
> From: apanella@molex.com [mailto:apanella@molex.com]
> Sent: Thursday, December 16, 1999 5:44 AM
> To: Bob Ross; ibis@eda.org
> Subject: RE: IBIS Meeting 12/17/99
> 
> 
> Bob / Kellee,
> 
> I have a prior meeting commitment starting at 10:00 on Dec. 17
> 
> Therefore, I unfortunately will not be able to attend the meeting...
> Kellee,
> would you be able to attend??
> 
> However,  I have not seen ANY  comments (zero, nada, zilch, 
> nothing, etc.)
> on
> the reflector with regards to the IBIS connector 
> specification.  So, is
> there
> really anything to talk about? From the lack of response.. 
> either everyone
> thinks it's great... or everyone hasn't read it...  Maybe... 
> if we can use
> the
> meeting to URGENTLY request more (some?) feedback!!
> 
> Either way... it would be nice to get feedback and question 
> with regards to
> the
> specification before we get into an open phone discussion, 
> such that there
> would
> be time to prepare concise answers or create a change to the
> specification...
> 
> Best Regards,
> _gus
> 
> 
> > -----Original Message-----
> > From: Bob Ross <bob_ross@mentorg.com> 
> > Sent: Monday, December 13, 1999 1:45 PM
> > To: ibis@eda.org
> > Subject: IBIS Meeting 12/17/99
> > 
> > 
> > 
> >                      IBIS Open Forum Meeting Agenda 
> >                                for 12/17/99
> > 
> >                  Bridge Number    Reservation #   Passcode
> >                  (916) 356-9200   2-368942        8917482
> >
>  <SNIP> 
> 
> 
From owner-ibis  Mon Dec 20 05:16:31 1999
Received: from bastion.power-x.co.uk (bastion.power-x.co.uk [62.232.19.201]) by server.eda.org (8.8.5/8.8.3) with ESMTP id FAA17926 for <ibis@eda.org>; Mon, 20 Dec 1999 05:16:23 -0800 (PST)
Received: from newhey (newhey.px.uk.com [172.16.18.44])
	by bastion.power-x.co.uk (8.9.3/8.9.3) with SMTP id NAA32168
	for <ibis@eda.org>; Mon, 20 Dec 1999 13:15:31 GMT
Reply-To: <chrisp@px.uk.com>
From: "Chris Potts" <chrisp@px.uk.com>
To: <ibis@eda.org>
Subject: Help, IBIS Warnings.
Date: Mon, 20 Dec 1999 13:15:30 -0000
Message-ID: <000201bf4aec$4a887f60$2c1210ac@px.uk.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0003_01BF4AEC.4A887F60"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

------=_NextPart_000_0003_01BF4AEC.4A887F60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I am attempting to create a IBIS model of a connector used in a system, the
signals come from a Motorola Differential PECL clock device so I have been
trying to utilise the models available for this item, however, when checking
my model I get the following warnings,

WARNING - Model 'PECL_OBUF3_5': MIN AC Falling Endpoints ( 1.22V,  1.98V)
not within
          0.015V (2%) of ( 1.22V,  1.87V) on VI curves for 50 Ohms to 1V
WARNING - Model 'PECL_OBUF3_5': MIN VI curves cannot drive through
Vmeas=1.9V
          given load Rref=50 Ohms to Vref=1.3V

Does anyone have any help regarding these errors as I am at a loss, attached
is a copy of my file.

Thanks in advance

Chris Potts



Mr Chris Potts BEng(Hons).
Design Engineer
PowerX Ltd
Tel: +44 0161 286 2000 ext 201
Fax: +44 0161 286 2202
E-Mail: chrisp@px.uk.com

------=_NextPart_000_0003_01BF4AEC.4A887F60
Content-Type: application/octet-stream;
	name="cdspedpk.ibs"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="cdspedpk.ibs"

|All Rights Reserved, Copyright(C) PowerX Ltd.=0A=
|Date : 17/12/1999 12:00:00 BST=0A=
|=0A=
[IBIS Ver] 2.1=0A=
[File Name] cdspedpk.ibs=0A=
[File Rev] 0.2=0A=
[Component] clkanddiagspeedpak=0A=
[Manufacturer] PowerX Ltd.=0A=
[Package]=0A=
| variable typ min max=0A=
R_pkg 150m 100m 200m=0A=
L_pkg 5.2nH 1.7nH 9.0nH=0A=
C_pkg 1.2pF 0.38pF 2.0pF=0A=
[Pin] signal_name model_name R_pin L_pin C_pin=0A=
1AX GND GND
1AY GND GND
1BX VCC33 POWER
1BY VCC33 POWER
1CX GND GND
1CY GND GND
1DX VCC33 POWER
1DY VCC33 POWER
2AX NC NC
2AY NC NC
2BX NC NC
2BY NC NC
2CX NC NC
2CY NC NC
2DX NC NC
2DY NC NC
3AX NC NC
3AY NC NC
3BX NC NC
3BY NC NC
3CX NC NC
3CY NC NC
3DX NC NC
3DY NC NC
4AX NC NC
4AY NC NC
4BX NC NC
4BY NC NC
4CX NC NC
4CY NC NC
4DX NC NC
4DY NC NC
5AX NC NC
5AY NC NC
5BX NC NC
5BY NC NC
5CX NC NC
5CY NC NC
5DX NC NC
5DY NC NC
6AX NC NC
6AY NC NC
6BX NC NC
6BY NC NC
6CX SCLK0_P PECL_OBUF3_5
6CY SCLK0_N PECL_OBUF3_5
6DX SCLK1_P PECL_OBUF3_5
6DY SCLK1_N PECL_OBUF3_5
7AX NC NC
7AY NC NC
7BX NC NC
7BY NC NC
7CX NC NC
7CY NC NC
7DX NC NC
7DY NC NC
8AX SCLK2_P PECL_OBUF3_5
8AY SCLK2_N PECL_OBUF3_5
8BX NC NC
8BY NC NC
8CX NC NC
8CY NC NC
8DX SCLK3_P PECL_OBUF3_5
8DY SCLK3_N PECL_OBUF3_5
9AX GND GND
9AY GND GND
9BX VCC33 POWER
9BY VCC33 POWER
9CX GND GND
9CY GND GND
9DX VCC33 POWER
9DY VCC33 POWER
11AX GND GND
11AY GND GND
11BX VCC33 POWER
11BY VCC33 POWER
11CX GND GND
11CY GND GND
11DX VCC33 POWER
11DY VCC33 POWER
12AX SCLK4_P PECL_OBUF3_5
12AY SCLK4_N PECL_OBUF3_5
12BX NC NC
12BY NC NC
12CX NC NC
12CY NC NC
12DX SCLK5_P PECL_OBUF3_5
12DY SCLK5_N PECL_OBUF3_5
13AX NC NC
13AY NC NC
13BX NC NC
13BY NC NC
13CX NC NC
13CY NC NC
13DX NC NC
13DY NC NC
14AX SCLK6_P PECL_OBUF3_5
14AY SCLK6_N PECL_OBUF3_5
14BX NC NC
14BY NC NC
14CX NC NC
14CY NC NC
14DX SCLK7_P PECL_OBUF3_5
14DY SCLK7_N PECL_OBUF3_5
15AX NC NC
15AY NC NC
15BX NC NC
15BY NC NC
15CX NC NC
15CY NC NC
15DX NC NC
15DY NC NC
16AX SCLK8_P PECL_OBUF3_5
16AY SCLK8_N PECL_OBUF3_5
16BX NC NC
16BY NC NC
16CX NC NC
16CY NC NC
16DX SCLK9_P PECL_OBUF3_5
16DY SCLK9_N PECL_OBUF3_5
17AX NC NC
17AY NC NC
17BX NC NC
17BY NC NC
17CX NC NC
17CY NC NC
17DX NC NC
17DY NC NC
18AX SCLK10_P PECL_OBUF3_5
18AY SCLK10_N PECL_OBUF3_5
18BX NC NC
18BY NC NC
18CX NC NC
18CY NC NC
18DX SCLK11_P PECL_OBUF3_5
18DY SCLK11_N PECL_OBUF3_5
19AX GND GND
19AY GND GND
19BX VCC33 POWER
19BY VCC33 POWER
19CX GND GND
19CY GND GND
19DX VCC33 POWER
19DY VCC33 POWER
21AX GND GND
21AY GND GND
21BX VCC33 POWER
21BY VCC33 POWER
21CX GND GND
21CY GND GND
21DX VCC33 POWER
21DY VCC33 POWER
22AX SCLK12_P PECL_OBUF3_5
22AY SCLK12_N PECL_OBUF3_5
22BX NC NC
22BY NC NC
22CX NC NC
22CY NC NC
22DX SCLK13_P PECL_OBUF3_5
22DY SCLK13_N PECL_OBUF3_5
23AX NC NC
23AY NC NC
23BX NC NC
23BY NC NC
23CX NC NC
23CY NC NC
23DX NC NC
23DY NC NC
24AX SCLK14_P PECL_OBUF3_5
24AY SCLK14_N PECL_OBUF3_5
24BX NC NC
24BY NC NC
24CX NC NC
24CY NC NC
24DX SCLK15_P PECL_OBUF3_5
24DY SCLK15_N PECL_OBUF3_5
25AX NC NC
25AY NC NC
25BX NC NC
25BY NC NC
25CX NC NC
25CY NC NC
25DX NC NC
25DY NC NC
26AX SCLK16_P PECL_OBUF3_5
26AY SCLK16_N PECL_OBUF3_5
26BX NC NC
26BY NC NC
26CX NC NC
26CY NC NC
26DX SCLK17_P PECL_OBUF3_5
26DY SCLK17_N PECL_OBUF3_5
27AX NC NC
27AY NC NC
27BX NC NC
27BY NC NC
27CX NC NC
27CY NC NC
27DX NC NC
27DY NC NC
28AX SCLK18_P PECL_OBUF3_5
28AY SCLK18_N PECL_OBUF3_5
28BX NC NC
28BY NC NC
28CX NC NC
28CY NC NC
28DX SCLK19_P PECL_OBUF3_5
28DY SCLK19_N PECL_OBUF3_5
29AX GND GND
29AY GND GND
29BX VCC33 POWER
29BY VCC33 POWER
29CX GND GND
29CY GND GND
29DX VCC33 POWER
29DY VCC33 POWER
31AX GND GND
31AY GND GND
31BX VCC33 POWER
31BY VCC33 POWER
31CX GND GND
31CY GND GND
31DX VCC33 POWER
31DY VCC33 POWER
32AX SCLK20_P PECL_OBUF3_5
32AY SCLK20_N PECL_OBUF3_5
32BX NC NC
32BY NC NC
32CX NC NC
32CY NC NC
32DX SCLK21_P PECL_OBUF3_5
32DY SCLK21_N PECL_OBUF3_5
33AX NC NC
33AY NC NC
33BX NC NC
33BY NC NC
33CX NC NC
33CY NC NC
33DX NC NC
33DY NC NC
34AX SCLK22_P PECL_OBUF3_5
34AY SCLK22_N PECL_OBUF3_5
34BX NC NC
34BY NC NC
34CX NC NC
34CY NC NC
34DX SCLK23_P PECL_OBUF3_5
34DY SCLK23_N PECL_OBUF3_5
35AX NC NC
35AY NC NC
35BX NC NC
35BY NC NC
35CX NC NC
35CY NC NC
35DX NC NC
35DY NC NC
36AX SCLK24_P PECL_OBUF3_5
36AY SCLK24_N PECL_OBUF3_5
36BX NC NC
36BY NC NC
36CX NC NC
36CY NC NC
36DX SCLK25_P PECL_OBUF3_5
36DY SCLK25_N PECL_OBUF3_5
37AX NC NC
37AY NC NC
37BX NC NC
37BY NC NC
37CX NC NC
37CY NC NC
37DX NC NC
37DY NC NC
38AX SCLK26_P PECL_OBUF3_5
38AY SCLK26_N PECL_OBUF3_5
38BX NC NC
38BY NC NC
38CX NC NC
38CY NC NC
38DX NC NC
38DY NC NC
39AX GND GND
39AY GND GND
39BX VCC33 POWER
39BY VCC33 POWER
39CX GND GND
39CY GND GND
39DX VCC33 POWER
39DY VCC33 POWER
41AX GND GND
41AY GND GND
41BX VCC33 POWER
41BY VCC33 POWER
41CX GND GND
41CY GND GND
41DX VCC33 POWER
41DY VCC33 POWER
42AX NC NC
42AY NC NC
42BX NC NC
42BY NC NC
42CX NC NC
42CY NC NC
42DX NC NC
42DY NC NC
43AX NC NC
43AY NC NC
43BX NC NC
43BY NC NC
43CX NC NC
43CY NC NC
43DX NC NC
43DY NC NC
44AX NC NC
44AY NC NC
44BX NC NC
44BY NC NC
44CX NC NC
44CY NC NC
44DX NC NC
44DY NC NC
45AX NC NC
45AY NC NC
45BX NC NC
45BY NC NC
45CX NC NC
45CY NC NC
45DX NC NC
45DY NC NC
46AX NC NC
46AY NC NC
46BX NC NC
46BY NC NC
46CX NC NC
46CY NC NC
46DX NC NC
46DY NC NC
47AX NC NC
47AY NC NC
47BX NC NC
47BY NC NC
47CX NC NC
47CY NC NC
47DX NC NC
47DY NC NC
48AX NC NC
48AY NC NC
48BX NC NC
48BY NC NC
48CX NC NC
48CY NC NC
48DX NC NC
48DY NC NC
49AX GND GND
49AY GND GND
49BX VCC33 POWER
49BY VCC33 POWER
49CX GND GND
49CY GND GND
49DX VCC33 POWER
49DY VCC33 POWER
|
[Diff Pin]  inv_pin  vdiff  tdelay_typ tdelay_min tdelay_max
|
6CX    6CY    0  0    NA    NA
6DX    6DY    0  0    NA    NA
8AX    8AY    0  0    NA    NA
8DX    8DY    0  0    NA    NA
12AX  12AY    0  0    NA    NA
12DX  12DY    0  0    NA    NA
14AX  14AY    0  0    NA    NA
14DX  14DY    0  0    NA    NA
16AX  16AY    0  0    NA    NA
16DX  16DY    0  0    NA    NA
18AX  18AY    0  0    NA    NA
18DX  18DY    0  0    NA    NA
22AX  22AY    0  0    NA    NA
22DX  22DY    0  0    NA    NA
24AX  24AY    0  0    NA    NA
24DX  24DY    0  0    NA    NA
26AX  26AY    0  0    NA    NA
26DX  26DY    0  0    NA    NA
28AX  28AY    0  0    NA    NA
28DX  28DY    0  0    NA    NA
32AX  32AY    0  0    NA    NA
32DX  32DY    0  0    NA    NA
34AX  34AY    0  0    NA    NA
34DX  34DY    0  0    NA    NA
36AX  36AY    0  0    NA    NA
36DX  36DY    0  0    NA    NA
38AX  38AY    0  0    NA    NA
|
|=0A=
|************************************************************************=

|                       Model PECL_OBUFXXX
|************************************************************************=

[Model]     PECL_OBUFXXX
Model_type  Output_ECL
Polarity    Non-Inverting
Vmeas =3D 1.9
Rref  =3D 50.0
Vref  =3D 1.3
|
|Variable            typ    min    max
C_comp              2.9p   2.0p   6.0p
|
|Variable            typ    min    max
[Temperature Range]  27      0     85
|
|Variable                  typ    min    max
[Voltage Range]            3.3    3.0    3.8
[Pulldown Reference]       3.3    3.0    3.8
[Power Clamp Reference]     3.3    3.0    3.8
[Gnd Clamp Reference]       0.0    0.0    0.0
|
[Pulldown]
|Volts    I(typ)    I(min)    I(max)
+3.00  -2.538e-01  -2.172e-01  -2.967e-01
+2.95  -2.476e-01  -2.122e-01  -2.870e-01
+2.90  -2.402e-01  -2.065e-01  -2.784e-01
+2.85  -2.295e-01  -1.987e-01  -2.701e-01
+2.80  -2.178e-01  -1.885e-01  -2.618e-01
+2.75  -2.082e-01  -1.778e-01  -2.534e-01
+2.70  -2.001e-01  -1.670e-01  -2.448e-01
+2.65  -1.927e-01  -1.560e-01  -2.360e-01
+2.60  -1.852e-01  -1.450e-01  -2.271e-01
+2.55  -1.776e-01  -1.344e-01  -2.179e-01
+2.50  -1.698e-01  -1.246e-01  -2.085e-01
+2.45  -1.619e-01  -1.164e-01  -1.988e-01
+2.40  -1.537e-01  -1.098e-01  -1.889e-01
+2.35  -1.453e-01  -1.036e-01  -1.787e-01
+2.30  -1.366e-01  -9.753e-02  -1.682e-01
+2.25  -1.277e-01  -9.131e-02  -1.573e-01
+2.20  -1.185e-01  -8.494e-02  -1.461e-01
+2.15  -1.091e-01  -7.842e-02  -1.345e-01
+2.10  -9.927e-02  -7.175e-02  -1.225e-01
+2.05  -8.914e-02  -6.492e-02  -1.101e-01
+2.00  -7.868e-02  -5.794e-02  -9.718e-02
+1.95  -6.787e-02  -5.084e-02  -8.377e-02
+1.90  -5.674e-02  -4.367e-02  -6.989e-02
+1.85  -4.536e-02  -3.656e-02  -5.561e-02
+1.80  -3.392e-02  -2.972e-02  -4.115e-02
+1.75  -2.278e-02  -2.332e-02  -2.705e-02
+1.70  -1.271e-02  -1.727e-02  -1.453e-02
+1.65  -5.044e-03  -1.147e-02  -5.634e-03
+1.60  -1.210e-03  -6.210e-03  -1.513e-03
+1.55  -2.016e-04  -2.243e-03  -3.289e-04
+1.50  -3.014e-05  -4.413e-04  -6.700e-05
+1.45  -4.426e-06  -5.910e-05  -1.346e-05
+1.40  +0.000e+00  -7.242e-06  -2.694e-06
+1.35  +0.000e+00  +0.000e+00  +0.000e+00
+1.30  +0.000e+00  +0.000e+00  +0.000e+00
+1.20  +0.000e+00  +0.000e+00  +0.000e+00
+1.00  +0.000e+00  +0.000e+00  +0.000e+00
+0.80  +0.000e+00  +0.000e+00  +0.000e+00
+0.60  +0.000e+00  +0.000e+00  +0.000e+00
+0.40  +0.000e+00  +0.000e+00  +0.000e+00
+0.20  +0.000e+00  +0.000e+00  +0.000e+00
+0.00  +0.000e+00  +0.000e+00  +0.000e+00
|
|
[Pullup]
|Volts    I(typ)    I(min)    I(max)
+3.00  -2.539e-01  -1.944e-01  -3.101e-01
+2.95  -2.493e-01  -1.901e-01  -3.045e-01
+2.90  -2.447e-01  -1.857e-01  -2.989e-01
+2.85  -2.401e-01  -1.813e-01  -2.933e-01
+2.80  -2.355e-01  -1.769e-01  -2.877e-01
+2.75  -2.309e-01  -1.724e-01  -2.822e-01
+2.70  -2.263e-01  -1.680e-01  -2.767e-01
+2.65  -2.218e-01  -1.636e-01  -2.712e-01
+2.60  -2.174e-01  -1.595e-01  -2.658e-01
+2.55  -2.129e-01  -1.556e-01  -2.604e-01
+2.50  -2.085e-01  -1.521e-01  -2.550e-01
+2.45  -2.040e-01  -1.485e-01  -2.495e-01
+2.40  -1.996e-01  -1.450e-01  -2.441e-01
+2.35  -1.951e-01  -1.414e-01  -2.387e-01
+2.30  -1.906e-01  -1.377e-01  -2.332e-01
+2.25  -1.861e-01  -1.340e-01  -2.278e-01
+2.20  -1.816e-01  -1.303e-01  -2.223e-01
+2.15  -1.771e-01  -1.265e-01  -2.169e-01
+2.10  -1.726e-01  -1.227e-01  -2.114e-01
+2.05  -1.680e-01  -1.188e-01  -2.059e-01
+2.00  -1.634e-01  -1.149e-01  -2.004e-01
+1.95  -1.588e-01  -1.109e-01  -1.949e-01
+1.90  -1.542e-01  -1.069e-01  -1.893e-01
+1.85  -1.494e-01  -1.028e-01  -1.837e-01
+1.80  -1.446e-01  -9.857e-02  -1.781e-01
+1.75  -1.397e-01  -9.432e-02  -1.725e-01
+1.70  -1.347e-01  -8.999e-02  -1.668e-01
+1.65  -1.295e-01  -8.559e-02  -1.611e-01
+1.60  -1.240e-01  -8.110e-02  -1.553e-01
+1.55  -1.181e-01  -7.652e-02  -1.494e-01
+1.50  -1.118e-01  -7.184e-02  -1.434e-01
+1.45  -1.052e-01  -6.707e-02  -1.371e-01
+1.40  -9.836e-02  -6.219e-02  -1.306e-01
+1.35  -9.124e-02  -5.720e-02  -1.237e-01
+1.30  -8.390e-02  -5.209e-02  -1.160e-01
+1.25  -7.632e-02  -4.686e-02  -1.074e-01
+1.20  -6.850e-02  -4.151e-02  -9.750e-02
+1.15  -6.041e-02  -3.603e-02  -8.636e-02
+1.10  -5.205e-02  -3.044e-02  -7.417e-02
+1.05  -4.336e-02  -2.474e-02  -6.118e-02
+1.00  -3.421e-02  -1.900e-02  -4.761e-02
+0.95  -2.451e-02  -1.332e-02  -3.382e-02
+0.90  -1.473e-02  -7.939e-03  -2.065e-02
+0.85  -6.396e-03  -3.458e-03  -9.729e-03
+0.80  -1.670e-03  -8.585e-04  -3.165e-03
+0.75  -2.880e-04  -1.267e-04  -7.529e-04
+0.70  -4.337e-05  -1.577e-05  -1.571e-04
+0.65  -6.378e-06  -1.916e-06  -3.172e-05
+0.60  +0.000e+00  +0.000e+00  -6.360e-06
+0.50  +0.000e+00  +0.000e+00  +0.000e+00
+0.40  +0.000e+00  +0.000e+00  +0.000e+00
+0.30  +0.000e+00  +0.000e+00  +0.000e+00
+0.20  +0.000e+00  +0.000e+00  +0.000e+00
+0.10  +0.000e+00  +0.000e+00  +0.000e+00
+0.00  +0.000e+00  +0.000e+00  +0.000e+00
|
|
[Ramp]
|Variable    typ    min    max
dV/dt_r  0.42/0.36n  0.35/0.36n  0.44/0.32n
dV/dt_f  0.43/0.36n  0.35/0.36n  0.42/0.28n
|
|
[Rising Waveform]
R_fixture =3D 50
C_fixture =3D 0.0p
V_fixture =3D 1.3
|
|Time    V(typ)   V(min)    V(max)
0.00e+00  +1.637e+00  +1.441e+00  +1.911e+00
2.00e-11  +1.649e+00  +1.444e+00  +1.937e+00
4.00e-11  +1.710e+00  +1.492e+00  +2.006e+00
6.00e-11  +1.760e+00  +1.532e+00  +2.062e+00
8.00e-11  +1.804e+00  +1.568e+00  +2.110e+00
1.00e-10  +1.846e+00  +1.601e+00  +2.157e+00
1.20e-10  +1.884e+00  +1.633e+00  +2.200e+00
1.40e-10  +1.918e+00  +1.661e+00  +2.236e+00
1.60e-10  +1.950e+00  +1.687e+00  +2.271e+00
1.80e-10  +1.981e+00  +1.712e+00  +2.306e+00
2.00e-10  +2.013e+00  +1.738e+00  +2.341e+00
2.20e-10  +2.039e+00  +1.763e+00  +2.373e+00
2.40e-10  +2.062e+00  +1.781e+00  +2.396e+00
2.60e-10  +2.084e+00  +1.799e+00  +2.419e+00
2.80e-10  +2.106e+00  +1.817e+00  +2.443e+00
3.00e-10  +2.128e+00  +1.835e+00  +2.466e+00
3.20e-10  +2.146e+00  +1.852e+00  +2.487e+00
3.40e-10  +2.162e+00  +1.864e+00  +2.503e+00
3.60e-10  +2.177e+00  +1.876e+00  +2.518e+00
3.80e-10  +2.192e+00  +1.888e+00  +2.534e+00
4.00e-10  +2.207e+00  +1.900e+00  +2.550e+00
4.20e-10  +2.219e+00  +1.912e+00  +2.564e+00
4.40e-10  +2.229e+00  +1.920e+00  +2.574e+00
4.60e-10  +2.239e+00  +1.928e+00  +2.585e+00
4.80e-10  +2.249e+00  +1.936e+00  +2.595e+00
5.00e-10  +2.259e+00  +1.944e+00  +2.606e+00
5.20e-10  +2.267e+00  +1.952e+00  +2.615e+00
5.40e-10  +2.273e+00  +1.958e+00  +2.621e+00
5.60e-10  +2.280e+00  +1.963e+00  +2.628e+00
5.80e-10  +2.287e+00  +1.969e+00  +2.634e+00
6.00e-10  +2.294e+00  +1.974e+00  +2.640e+00
6.20e-10  +2.299e+00  +1.979e+00  +2.646e+00
6.40e-10  +2.304e+00  +1.983e+00  +2.649e+00
6.60e-10  +2.308e+00  +1.987e+00  +2.652e+00
6.80e-10  +2.313e+00  +1.990e+00  +2.655e+00
7.00e-10  +2.318e+00  +1.994e+00  +2.658e+00
7.20e-10  +2.322e+00  +1.998e+00  +2.661e+00
7.40e-10  +2.325e+00  +2.000e+00  +2.662e+00
7.60e-10  +2.328e+00  +2.003e+00  +2.664e+00
7.80e-10  +2.331e+00  +2.005e+00  +2.665e+00
8.00e-10  +2.335e+00  +2.008e+00  +2.666e+00
8.20e-10  +2.337e+00  +2.010e+00  +2.667e+00
8.40e-10  +2.339e+00  +2.012e+00  +2.668e+00
8.60e-10  +2.342e+00  +2.013e+00  +2.669e+00
8.80e-10  +2.344e+00  +2.015e+00  +2.669e+00
9.00e-10  +2.346e+00  +2.017e+00  +2.670e+00
9.20e-10  +2.348e+00  +2.018e+00  +2.670e+00
9.40e-10  +2.349e+00  +2.020e+00  +2.671e+00
9.60e-10  +2.351e+00  +2.021e+00  +2.671e+00
9.80e-10  +2.352e+00  +2.022e+00  +2.671e+00
1.00e-09  +2.353e+00  +2.023e+00  +2.671e+00
1.02e-09  +2.355e+00  +2.024e+00  +2.672e+00
1.04e-09  +2.356e+00  +2.025e+00  +2.672e+00
1.06e-09  +2.357e+00  +2.026e+00  +2.672e+00
1.08e-09  +2.357e+00  +2.027e+00  +2.672e+00
1.10e-09  +2.358e+00  +2.028e+00  +2.672e+00
1.12e-09  +2.359e+00  +2.028e+00  +2.672e+00
1.14e-09  +2.360e+00  +2.029e+00  +2.672e+00
1.16e-09  +2.360e+00  +2.030e+00  +2.673e+00
1.18e-09  +2.361e+00  +2.030e+00  +2.673e+00
1.20e-09  +2.361e+00  +2.031e+00  +2.673e+00
1.22e-09  +2.362e+00  +2.031e+00  +2.673e+00
1.24e-09  +2.362e+00  +2.031e+00  +2.673e+00
1.26e-09  +2.362e+00  +2.032e+00  +2.673e+00
1.28e-09  +2.363e+00  +2.032e+00  +2.673e+00
1.30e-09  +2.363e+00  +2.033e+00  +2.673e+00
1.32e-09  +2.364e+00  +2.033e+00  +2.673e+00
1.34e-09  +2.364e+00  +2.033e+00  +2.673e+00
1.36e-09  +2.364e+00  +2.034e+00  +2.673e+00
1.38e-09  +2.364e+00  +2.034e+00  +2.673e+00
1.40e-09  +2.364e+00  +2.034e+00  +2.673e+00
1.42e-09  +2.365e+00  +2.034e+00  +2.673e+00
1.44e-09  +2.365e+00  +2.035e+00  +2.673e+00
1.46e-09  +2.365e+00  +2.035e+00  +2.673e+00
1.48e-09  +2.365e+00  +2.035e+00  +2.673e+00
1.50e-09  +2.365e+00  +2.035e+00  +2.673e+00
1.52e-09  +2.365e+00  +2.035e+00  +2.673e+00
1.54e-09  +2.365e+00  +2.035e+00  +2.673e+00
1.56e-09  +2.365e+00  +2.035e+00  +2.673e+00
1.58e-09  +2.365e+00  +2.036e+00  +2.673e+00
1.60e-09  +2.365e+00  +2.036e+00  +2.673e+00
1.62e-09  +2.365e+00  +2.036e+00  +2.673e+00
1.64e-09  +2.365e+00  +2.036e+00  +2.673e+00
1.66e-09  +2.366e+00  +2.036e+00  +2.673e+00
1.68e-09  +2.366e+00  +2.036e+00  +2.673e+00
1.70e-09  +2.366e+00  +2.036e+00  +2.673e+00
1.72e-09  +2.366e+00  +2.036e+00  +2.673e+00
1.74e-09  +2.366e+00  +2.036e+00  +2.673e+00
1.76e-09  +2.366e+00  +2.037e+00  +2.674e+00
1.78e-09  +2.366e+00  +2.037e+00  +2.674e+00
1.80e-09  +2.366e+00  +2.037e+00  +2.674e+00
1.82e-09  +2.366e+00  +2.037e+00  +2.674e+00
1.84e-09  +2.366e+00  +2.037e+00  +2.674e+00
1.86e-09  +2.366e+00  +2.037e+00  +2.674e+00
1.88e-09  +2.366e+00  +2.037e+00  +2.674e+00
1.90e-09  +2.366e+00  +2.037e+00  +2.674e+00
1.92e-09  +2.366e+00  +2.037e+00  +2.674e+00
1.96e-09  +2.366e+00  +2.037e+00  +2.674e+00
2.00e-09  +2.366e+00  +2.037e+00  +2.674e+00
1.00e-08  +2.366e+00  +2.037e+00  +2.674e+00
|
|
[Falling Waveform]
R_fixture =3D 50
C_fixture =3D 0.0p
V_fixture =3D 1.3
|
|Time    V(typ)   V(min)    V(max)
0.00e+00  +2.366e+00  +2.037e+00  +2.674e+00
2.00e-11  +2.390e+00  +2.063e+00  +2.692e+00
4.00e-11  +2.336e+00  +2.025e+00  +2.614e+00
6.00e-11  +2.258e+00  +1.962e+00  +2.536e+00
8.00e-11  +2.200e+00  +1.903e+00  +2.482e+00
1.00e-10  +2.156e+00  +1.861e+00  +2.434e+00
1.20e-10  +2.120e+00  +1.831e+00  +2.389e+00
1.40e-10  +2.087e+00  +1.804e+00  +2.355e+00
1.60e-10  +2.056e+00  +1.779e+00  +2.321e+00
1.80e-10  +2.025e+00  +1.754e+00  +2.287e+00
2.00e-10  +1.993e+00  +1.730e+00  +2.253e+00
2.20e-10  +1.967e+00  +1.706e+00  +2.221e+00
2.40e-10  +1.944e+00  +1.688e+00  +2.196e+00
2.60e-10  +1.921e+00  +1.670e+00  +2.170e+00
2.80e-10  +1.897e+00  +1.652e+00  +2.144e+00
3.00e-10  +1.874e+00  +1.634e+00  +2.119e+00
3.20e-10  +1.856e+00  +1.617e+00  +2.095e+00
3.40e-10  +1.840e+00  +1.605e+00  +2.079e+00
3.60e-10  +1.825e+00  +1.593e+00  +2.063e+00
3.80e-10  +1.809e+00  +1.581e+00  +2.047e+00
4.00e-10  +1.794e+00  +1.569e+00  +2.031e+00
4.20e-10  +1.781e+00  +1.558e+00  +2.016e+00
4.40e-10  +1.771e+00  +1.550e+00  +2.005e+00
4.60e-10  +1.760e+00  +1.543e+00  +1.993e+00
4.80e-10  +1.750e+00  +1.535e+00  +1.982e+00
5.00e-10  +1.740e+00  +1.527e+00  +1.971e+00
5.20e-10  +1.731e+00  +1.520e+00  +1.961e+00
5.40e-10  +1.724e+00  +1.514e+00  +1.954e+00
5.60e-10  +1.717e+00  +1.509e+00  +1.948e+00
5.80e-10  +1.710e+00  +1.504e+00  +1.942e+00
6.00e-10  +1.703e+00  +1.499e+00  +1.936e+00
6.20e-10  +1.697e+00  +1.494e+00  +1.930e+00
6.40e-10  +1.693e+00  +1.490e+00  +1.927e+00
6.60e-10  +1.688e+00  +1.487e+00  +1.925e+00
6.80e-10  +1.684e+00  +1.483e+00  +1.922e+00
7.00e-10  +1.679e+00  +1.480e+00  +1.919e+00
7.20e-10  +1.675e+00  +1.477e+00  +1.917e+00
7.40e-10  +1.672e+00  +1.474e+00  +1.916e+00
7.60e-10  +1.669e+00  +1.472e+00  +1.915e+00
7.80e-10  +1.666e+00  +1.470e+00  +1.913e+00
8.00e-10  +1.663e+00  +1.467e+00  +1.913e+00
8.20e-10  +1.660e+00  +1.465e+00  +1.912e+00
8.40e-10  +1.658e+00  +1.464e+00  +1.911e+00
8.60e-10  +1.656e+00  +1.462e+00  +1.911e+00
8.80e-10  +1.654e+00  +1.460e+00  +1.911e+00
9.00e-10  +1.652e+00  +1.459e+00  +1.911e+00
9.20e-10  +1.651e+00  +1.457e+00  +1.911e+00
9.40e-10  +1.649e+00  +1.456e+00  +1.911e+00
9.60e-10  +1.648e+00  +1.455e+00  +1.910e+00
9.80e-10  +1.647e+00  +1.454e+00  +1.910e+00
1.00e-09  +1.646e+00  +1.453e+00  +1.910e+00
1.02e-09  +1.645e+00  +1.452e+00  +1.910e+00
1.04e-09  +1.644e+00  +1.451e+00  +1.910e+00
1.06e-09  +1.643e+00  +1.451e+00  +1.910e+00
1.08e-09  +1.642e+00  +1.450e+00  +1.910e+00
1.10e-09  +1.642e+00  +1.449e+00  +1.910e+00
1.12e-09  +1.641e+00  +1.449e+00  +1.910e+00
1.14e-09  +1.641e+00  +1.448e+00  +1.910e+00
1.16e-09  +1.640e+00  +1.448e+00  +1.910e+00
1.18e-09  +1.640e+00  +1.447e+00  +1.910e+00
1.20e-09  +1.639e+00  +1.447e+00  +1.910e+00
1.22e-09  +1.639e+00  +1.446e+00  +1.910e+00
1.24e-09  +1.639e+00  +1.446e+00  +1.910e+00
1.26e-09  +1.639e+00  +1.446e+00  +1.911e+00
1.28e-09  +1.638e+00  +1.445e+00  +1.911e+00
1.30e-09  +1.638e+00  +1.445e+00  +1.911e+00
1.32e-09  +1.638e+00  +1.444e+00  +1.911e+00
1.34e-09  +1.638e+00  +1.444e+00  +1.911e+00
1.36e-09  +1.638e+00  +1.444e+00  +1.911e+00
1.38e-09  +1.637e+00  +1.444e+00  +1.911e+00
1.40e-09  +1.637e+00  +1.444e+00  +1.911e+00
1.42e-09  +1.637e+00  +1.443e+00  +1.911e+00
1.44e-09  +1.637e+00  +1.443e+00  +1.911e+00
1.46e-09  +1.637e+00  +1.443e+00  +1.911e+00
1.48e-09  +1.637e+00  +1.443e+00  +1.911e+00
1.50e-09  +1.637e+00  +1.443e+00  +1.911e+00
1.52e-09  +1.637e+00  +1.443e+00  +1.911e+00
1.54e-09  +1.637e+00  +1.442e+00  +1.911e+00
1.56e-09  +1.637e+00  +1.442e+00  +1.911e+00
1.58e-09  +1.637e+00  +1.442e+00  +1.911e+00
1.60e-09  +1.637e+00  +1.442e+00  +1.911e+00
1.62e-09  +1.637e+00  +1.442e+00  +1.911e+00
1.64e-09  +1.637e+00  +1.442e+00  +1.911e+00
1.66e-09  +1.637e+00  +1.442e+00  +1.911e+00
1.68e-09  +1.637e+00  +1.442e+00  +1.911e+00
1.70e-09  +1.637e+00  +1.442e+00  +1.911e+00
1.72e-09  +1.637e+00  +1.442e+00  +1.911e+00
1.74e-09  +1.637e+00  +1.442e+00  +1.911e+00
1.76e-09  +1.637e+00  +1.442e+00  +1.911e+00
1.78e-09  +1.637e+00  +1.442e+00  +1.911e+00
1.80e-09  +1.637e+00  +1.442e+00  +1.911e+00
1.82e-09  +1.637e+00  +1.441e+00  +1.911e+00
1.84e-09  +1.637e+00  +1.441e+00  +1.911e+00
1.86e-09  +1.637e+00  +1.441e+00  +1.911e+00
1.88e-09  +1.637e+00  +1.441e+00  +1.911e+00
1.90e-09  +1.637e+00  +1.441e+00  +1.911e+00
1.92e-09  +1.637e+00  +1.441e+00  +1.911e+00
1.96e-09  +1.637e+00  +1.441e+00  +1.911e+00
2.00e-09  +1.637e+00  +1.441e+00  +1.911e+00
1.00e-08  +1.637e+00  +1.441e+00  +1.911e+00
|
|=0A=
| [End Model]
|
|************************************************************************=

|                       Model PECL_OBUF3_5
|************************************************************************=

[Model]     PECL_OBUF3_5
Model_type  Output_ECL
Polarity    Non-Inverting
Vmeas =3D 1.9
Rref  =3D 50.0
Vref  =3D 1.3
|
|Variable            typ    min    max
C_comp              2.9p   2.0p   6.0p
|
|Variable            typ    min    max
[Temperature Range]  27      0     85
|
|Variable                  typ    min    max
[Voltage Range]            3.3    3.0    3.8
[Pulldown Reference]       3.3    3.0    3.8
[Power Clamp Reference]     3.3    3.0    3.8
[Gnd Clamp Reference]       0.0    0.0    0.0
|
[Pulldown]
|Volts    I(typ)    I(min)    I(max)
+3.00  -2.290e-01  -1.623e-01  -2.832e-01
+2.90  -2.152e-01  -1.523e-01  -2.603e-01
+2.80  -2.010e-01  -1.419e-01  -2.422e-01
+2.70  -1.862e-01  -1.312e-01  -2.240e-01
+2.60  -1.707e-01  -1.201e-01  -2.050e-01
+2.50  -1.544e-01  -1.085e-01  -1.850e-01
+2.40  -1.372e-01  -9.633e-02  -1.637e-01
+2.30  -1.188e-01  -8.353e-02  -1.409e-01
+2.20  -9.534e-02  -6.703e-02  -1.121e-01
+2.10  -6.279e-02  -4.463e-02  -7.246e-02
+2.00  -3.135e-02  -2.767e-02  -2.895e-02
+1.90  -1.237e-02  -1.594e-02  -2.791e-03
+1.80  -1.400e-03  -5.245e-03  -8.464e-05
+1.70  -3.654e-05  -2.996e-04  -3.166e-06
+1.60  +0.000e+00  -4.739e-06  +0.000e+00
+1.50  +0.000e+00  +0.000e+00  +0.000e+00
+1.00  +0.000e+00  +0.000e+00  +0.000e+00
+0.50  +0.000e+00  +0.000e+00  +0.000e+00
+0.00  +0.000e+00  +0.000e+00  +0.000e+00
|
|
[Pullup]
|Volts    I(typ)    I(min)    I(max)
+3.00  -2.528e-01  -1.876e-01  -3.089e-01
+2.90  -2.436e-01  -1.790e-01  -2.977e-01
+2.80  -2.346e-01  -1.709e-01  -2.869e-01
+2.70  -2.258e-01  -1.639e-01  -2.761e-01
+2.60  -2.169e-01  -1.571e-01  -2.653e-01
+2.50  -2.081e-01  -1.503e-01  -2.545e-01
+2.40  -1.992e-01  -1.433e-01  -2.437e-01
+2.30  -1.902e-01  -1.361e-01  -2.328e-01
+2.20  -1.812e-01  -1.288e-01  -2.219e-01
+2.10  -1.721e-01  -1.212e-01  -2.110e-01
+2.00  -1.630e-01  -1.135e-01  -2.000e-01
+1.90  -1.536e-01  -1.055e-01  -1.889e-01
+1.80  -1.440e-01  -9.734e-02  -1.777e-01
+1.70  -1.339e-01  -8.885e-02  -1.664e-01
+1.60  -1.229e-01  -8.005e-02  -1.548e-01
+1.50  -1.106e-01  -7.090e-02  -1.426e-01
+1.40  -9.719e-02  -6.136e-02  -1.280e-01
+1.30  -8.183e-02  -5.134e-02  -1.030e-01
+1.20  -5.386e-02  -3.547e-02  -6.495e-02
+1.10  -1.747e-02  -1.112e-02  -2.130e-02
+1.00  -3.767e-04  -1.566e-04  -8.210e-04
+0.90  -1.551e-06  +0.000e+00  -8.754e-06
+0.80  +0.000e+00  +0.000e+00  +0.000e+00
+0.60  +0.000e+00  +0.000e+00  +0.000e+00
+0.40  +0.000e+00  +0.000e+00  +0.000e+00
+0.20  +0.000e+00  +0.000e+00  +0.000e+00
+0.00  +0.000e+00  +0.000e+00  +0.000e+00
|
|
[Ramp]
|Variable    typ    min    max
dV/dt_r  0.48/0.32n  0.46/0.35n  0.49/0.26n
dV/dt_f  0.47/0.30n  0.45/0.34n  0.48/0.25n
|
|
[Rising Waveform]
R_fixture =3D 50
C_fixture =3D 0.0p
V_fixture =3D 1.3
V_fixture_min =3D 1.0
V_fixture_max =3D 1.8
|
|Time    V(typ)   V(min)    V(max)
0.00e+00  +1.517e+00  +1.219e+00  +2.013e+00
2.00e-11  +1.537e+00  +1.236e+00  +2.041e+00
4.00e-11  +1.588e+00  +1.279e+00  +2.104e+00
6.00e-11  +1.645e+00  +1.331e+00  +2.167e+00
8.00e-11  +1.697e+00  +1.380e+00  +2.222e+00
1.00e-10  +1.744e+00  +1.424e+00  +2.274e+00
1.20e-10  +1.790e+00  +1.466e+00  +2.321e+00
1.40e-10  +1.831e+00  +1.502e+00  +2.363e+00
1.60e-10  +1.867e+00  +1.537e+00  +2.405e+00
1.80e-10  +1.903e+00  +1.572e+00  +2.447e+00
2.00e-10  +1.939e+00  +1.607e+00  +2.490e+00
2.20e-10  +1.975e+00  +1.635e+00  +2.523e+00
2.40e-10  +2.005e+00  +1.659e+00  +2.552e+00
2.60e-10  +2.029e+00  +1.683e+00  +2.580e+00
2.80e-10  +2.052e+00  +1.708e+00  +2.609e+00
3.00e-10  +2.076e+00  +1.732e+00  +2.637e+00
3.20e-10  +2.100e+00  +1.751e+00  +2.660e+00
3.40e-10  +2.120e+00  +1.767e+00  +2.679e+00
3.60e-10  +2.136e+00  +1.783e+00  +2.698e+00
3.80e-10  +2.152e+00  +1.799e+00  +2.717e+00
4.00e-10  +2.168e+00  +1.815e+00  +2.736e+00
4.20e-10  +2.184e+00  +1.827e+00  +2.751e+00
4.40e-10  +2.198e+00  +1.839e+00  +2.763e+00
4.60e-10  +2.209e+00  +1.849e+00  +2.774e+00
4.80e-10  +2.220e+00  +1.860e+00  +2.781e+00
5.00e-10  +2.231e+00  +1.871e+00  +2.788e+00
5.20e-10  +2.242e+00  +1.880e+00  +2.795e+00
5.40e-10  +2.251e+00  +1.887e+00  +2.802e+00
5.60e-10  +2.258e+00  +1.894e+00  +2.808e+00
5.80e-10  +2.265e+00  +1.901e+00  +2.810e+00
6.00e-10  +2.273e+00  +1.909e+00  +2.812e+00
6.20e-10  +2.280e+00  +1.914e+00  +2.815e+00
6.40e-10  +2.285e+00  +1.919e+00  +2.817e+00
6.60e-10  +2.290e+00  +1.924e+00  +2.819e+00
6.80e-10  +2.294e+00  +1.929e+00  +2.820e+00
7.00e-10  +2.298e+00  +1.934e+00  +2.821e+00
7.20e-10  +2.302e+00  +1.938e+00  +2.821e+00
7.40e-10  +2.305e+00  +1.941e+00  +2.822e+00
7.60e-10  +2.307e+00  +1.945e+00  +2.823e+00
7.80e-10  +2.309e+00  +1.948e+00  +2.823e+00
8.00e-10  +2.311e+00  +1.951e+00  +2.823e+00
8.20e-10  +2.313e+00  +1.954e+00  +2.823e+00
8.40e-10  +2.314e+00  +1.956e+00  +2.824e+00
8.60e-10  +2.315e+00  +1.958e+00  +2.824e+00
8.80e-10  +2.316e+00  +1.961e+00  +2.824e+00
9.00e-10  +2.317e+00  +1.963e+00  +2.824e+00
9.20e-10  +2.317e+00  +1.965e+00  +2.824e+00
9.40e-10  +2.318e+00  +1.966e+00  +2.824e+00
9.60e-10  +2.318e+00  +1.968e+00  +2.825e+00
9.80e-10  +2.318e+00  +1.969e+00  +2.825e+00
1.00e-09  +2.319e+00  +1.971e+00  +2.825e+00
1.02e-09  +2.319e+00  +1.972e+00  +2.825e+00
1.04e-09  +2.319e+00  +1.973e+00  +2.825e+00
1.06e-09  +2.320e+00  +1.974e+00  +2.825e+00
1.08e-09  +2.320e+00  +1.975e+00  +2.825e+00
1.10e-09  +2.320e+00  +1.976e+00  +2.825e+00
1.12e-09  +2.320e+00  +1.976e+00  +2.825e+00
1.14e-09  +2.320e+00  +1.977e+00  +2.825e+00
1.16e-09  +2.320e+00  +1.977e+00  +2.825e+00
1.18e-09  +2.320e+00  +1.978e+00  +2.825e+00
1.20e-09  +2.320e+00  +1.979e+00  +2.825e+00
1.22e-09  +2.320e+00  +1.979e+00  +2.825e+00
1.24e-09  +2.320e+00  +1.979e+00  +2.825e+00
1.26e-09  +2.320e+00  +1.980e+00  +2.825e+00
1.28e-09  +2.321e+00  +1.980e+00  +2.825e+00
1.30e-09  +2.321e+00  +1.980e+00  +2.825e+00
1.32e-09  +2.321e+00  +1.981e+00  +2.825e+00
1.34e-09  +2.321e+00  +1.981e+00  +2.825e+00
1.36e-09  +2.321e+00  +1.981e+00  +2.825e+00
1.38e-09  +2.321e+00  +1.981e+00  +2.825e+00
1.40e-09  +2.321e+00  +1.981e+00  +2.825e+00
1.42e-09  +2.321e+00  +1.982e+00  +2.825e+00
1.44e-09  +2.321e+00  +1.982e+00  +2.825e+00
1.46e-09  +2.321e+00  +1.982e+00  +2.825e+00
1.48e-09  +2.321e+00  +1.982e+00  +2.825e+00
1.50e-09  +2.321e+00  +1.982e+00  +2.825e+00
1.60e-09  +2.321e+00  +1.982e+00  +2.825e+00
1.70e-09  +2.321e+00  +1.983e+00  +2.825e+00
1.80e-09  +2.321e+00  +1.983e+00  +2.825e+00
1.90e-09  +2.321e+00  +1.983e+00  +2.825e+00
2.00e-09  +2.321e+00  +1.983e+00  +2.825e+00
1.00e-08  +2.321e+00  +1.983e+00  +2.825e+00
|
|
[Falling Waveform]
R_fixture =3D 50
C_fixture =3D 0.0p
V_fixture =3D 1.3
V_fixture_min =3D 1.0
V_fixture_max =3D 1.8
|
|Time    V(typ)   V(min)    V(max)
0.00e+00  +2.321e+00  +1.983e+00  +2.825e+00
2.00e-11  +2.316e+00  +1.978e+00  +2.814e+00
4.00e-11  +2.271e+00  +1.944e+00  +2.750e+00
6.00e-11  +2.201e+00  +1.883e+00  +2.668e+00
8.00e-11  +2.140e+00  +1.819e+00  +2.600e+00
1.00e-10  +2.089e+00  +1.770e+00  +2.545e+00
1.20e-10  +2.044e+00  +1.728e+00  +2.498e+00
1.40e-10  +1.999e+00  +1.688e+00  +2.458e+00
1.60e-10  +1.959e+00  +1.657e+00  +2.417e+00
1.80e-10  +1.927e+00  +1.625e+00  +2.376e+00
2.00e-10  +1.895e+00  +1.594e+00  +2.335e+00
2.20e-10  +1.862e+00  +1.563e+00  +2.302e+00
2.40e-10  +1.830e+00  +1.533e+00  +2.272e+00
2.60e-10  +1.801e+00  +1.511e+00  +2.243e+00
2.80e-10  +1.778e+00  +1.488e+00  +2.213e+00
3.00e-10  +1.755e+00  +1.466e+00  +2.184e+00
3.20e-10  +1.732e+00  +1.444e+00  +2.162e+00
3.40e-10  +1.709e+00  +1.423e+00  +2.143e+00
3.60e-10  +1.689e+00  +1.409e+00  +2.125e+00
3.80e-10  +1.674e+00  +1.395e+00  +2.107e+00
4.00e-10  +1.659e+00  +1.380e+00  +2.089e+00
4.20e-10  +1.645e+00  +1.366e+00  +2.075e+00
4.40e-10  +1.630e+00  +1.353e+00  +2.063e+00
4.60e-10  +1.617e+00  +1.343e+00  +2.054e+00
4.80e-10  +1.607e+00  +1.333e+00  +2.048e+00
5.00e-10  +1.597e+00  +1.324e+00  +2.042e+00
5.20e-10  +1.587e+00  +1.315e+00  +2.036e+00
5.40e-10  +1.577e+00  +1.305e+00  +2.030e+00
5.60e-10  +1.569e+00  +1.299e+00  +2.024e+00
5.80e-10  +1.562e+00  +1.293e+00  +2.022e+00
6.00e-10  +1.556e+00  +1.286e+00  +2.021e+00
6.20e-10  +1.550e+00  +1.280e+00  +2.019e+00
6.40e-10  +1.544e+00  +1.274e+00  +2.017e+00
6.60e-10  +1.539e+00  +1.270e+00  +2.016e+00
6.80e-10  +1.536e+00  +1.266e+00  +2.015e+00
7.00e-10  +1.533e+00  +1.262e+00  +2.015e+00
7.20e-10  +1.530e+00  +1.258e+00  +2.014e+00
7.40e-10  +1.527e+00  +1.254e+00  +2.014e+00
7.60e-10  +1.524e+00  +1.251e+00  +2.013e+00
7.80e-10  +1.523e+00  +1.248e+00  +2.013e+00
8.00e-10  +1.522e+00  +1.246e+00  +2.013e+00
8.20e-10  +1.521e+00  +1.243e+00  +2.013e+00
8.40e-10  +1.520e+00  +1.240e+00  +2.013e+00
8.60e-10  +1.519e+00  +1.238e+00  +2.013e+00
8.80e-10  +1.518e+00  +1.237e+00  +2.013e+00
9.00e-10  +1.518e+00  +1.235e+00  +2.013e+00
9.20e-10  +1.518e+00  +1.233e+00  +2.013e+00
9.40e-10  +1.517e+00  +1.232e+00  +2.013e+00
9.60e-10  +1.517e+00  +1.230e+00  +2.013e+00
9.80e-10  +1.517e+00  +1.229e+00  +2.013e+00
1.00e-09  +1.517e+00  +1.228e+00  +2.013e+00
1.02e-09  +1.517e+00  +1.227e+00  +2.013e+00
1.04e-09  +1.517e+00  +1.226e+00  +2.013e+00
1.06e-09  +1.516e+00  +1.225e+00  +2.013e+00
1.08e-09  +1.516e+00  +1.225e+00  +2.013e+00
1.10e-09  +1.516e+00  +1.224e+00  +2.013e+00
1.12e-09  +1.516e+00  +1.224e+00  +2.013e+00
1.14e-09  +1.516e+00  +1.223e+00  +2.013e+00
1.16e-09  +1.516e+00  +1.222e+00  +2.013e+00
1.18e-09  +1.516e+00  +1.222e+00  +2.013e+00
1.20e-09  +1.517e+00  +1.222e+00  +2.013e+00
1.22e-09  +1.517e+00  +1.222e+00  +2.013e+00
1.24e-09  +1.517e+00  +1.221e+00  +2.013e+00
1.26e-09  +1.517e+00  +1.221e+00  +2.013e+00
1.28e-09  +1.517e+00  +1.221e+00  +2.013e+00
1.30e-09  +1.517e+00  +1.220e+00  +2.013e+00
1.32e-09  +1.517e+00  +1.220e+00  +2.013e+00
1.34e-09  +1.517e+00  +1.220e+00  +2.013e+00
1.36e-09  +1.517e+00  +1.220e+00  +2.013e+00
1.38e-09  +1.517e+00  +1.220e+00  +2.013e+00
1.40e-09  +1.517e+00  +1.220e+00  +2.013e+00
1.42e-09  +1.517e+00  +1.220e+00  +2.013e+00
1.44e-09  +1.517e+00  +1.220e+00  +2.013e+00
1.46e-09  +1.517e+00  +1.220e+00  +2.013e+00
1.48e-09  +1.517e+00  +1.220e+00  +2.013e+00
1.50e-09  +1.517e+00  +1.220e+00  +2.013e+00
1.60e-09  +1.517e+00  +1.219e+00  +2.013e+00
1.70e-09  +1.517e+00  +1.219e+00  +2.013e+00
1.80e-09  +1.517e+00  +1.219e+00  +2.013e+00
1.90e-09  +1.517e+00  +1.219e+00  +2.013e+00
2.00e-09  +1.517e+00  +1.219e+00  +2.013e+00
1.00e-08  +1.517e+00  +1.219e+00  +2.013e+00
|
| [End Model]
|
[End]=0A=
|=0A=
|Reference Libraries=0A=
|PKG Lib  =3D /asic/fjtool2/ibis/lib/CE61/ver2.1/pkg.lib=0A=
|Wire Lib =3D /asic/fjtool2/ibis/lib/CE61/ver2.1/wire.lib=0A=
|I/O Lib  =3D /asic/fjtool2/ibis/lib/CE61/ver2.1/io.lib=0A=
|  Model =3D PECL_OBUFXXX
|  Model =3D PECL_OBUF3_5=0A=

------=_NextPart_000_0003_01BF4AEC.4A887F60--

From owner-ibis  Mon Dec 20 05:47:59 1999
Received: from exchtp02.via.com.tw ([202.145.217.204]) by server.eda.org (8.8.5/8.8.3) with ESMTP id FAA18120 for <ibis@eda.org>; Mon, 20 Dec 1999 05:47:58 -0800 (PST)
Received: by EXCHANGE2 with Internet Mail Service (5.5.2232.9)
	id <Y6DNQ3YP>; Mon, 20 Dec 1999 21:46:39 +0800
Message-ID: <9BADB79F06B3D211974800A0C92BD8A009C1CE@EXCHANGE2>
From: Daniel Wei <DanielWei@via.com.tw>
To: "'ibis@eda.org'" <ibis@eda.org>
Subject: ??: Help, IBIS Warnings.
Date: Mon, 20 Dec 1999 21:46:29 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id FAA18121

Increase the value specified at [Sim time] in the X.s2i file, then run
s2ibis2 again.

Daniel Wei

VIA Technologies, Inc.

-----­ì©l¶l¥ó-----
±H¥óªÌ: Chris Potts [mailto:chrisp@px.uk.com]
±H¥ó¤é´Á: 1999¦~12¤ë20¤é PM 09:16
¦¬¥óªÌ: ibis@eda.org
¥D¦®: Help, IBIS Warnings.


I am attempting to create a IBIS model of a connector used in a system, the
signals come from a Motorola Differential PECL clock device so I have been
trying to utilise the models available for this item, however, when checking
my model I get the following warnings,

WARNING - Model 'PECL_OBUF3_5': MIN AC Falling Endpoints ( 1.22V,  1.98V)
not within
          0.015V (2%) of ( 1.22V,  1.87V) on VI curves for 50 Ohms to 1V
WARNING - Model 'PECL_OBUF3_5': MIN VI curves cannot drive through
Vmeas=1.9V
          given load Rref=50 Ohms to Vref=1.3V

Does anyone have any help regarding these errors as I am at a loss, attached
is a copy of my file.

Thanks in advance

Chris Potts



Mr Chris Potts BEng(Hons).
Design Engineer
PowerX Ltd
Tel: +44 0161 286 2000 ext 201
Fax: +44 0161 286 2202
E-Mail: chrisp@px.uk.com
From owner-ibis  Tue Dec 21 11:55:25 1999
Received: from intermailhost.viewlogic.com (intermailhost.viewlogic.com [139.181.6.17]) by server.eda.org (8.8.5/8.8.3) with ESMTP id LAA26097 for <ibis@eda.org>; Tue, 21 Dec 1999 11:55:24 -0800 (PST)
Received: from mailhost.viewlogic.com (mailhost.viewlogic.com [139.181.3.35])
	by intermailhost.viewlogic.com (8.8.8/8.8.7) with ESMTP id OAA03324
	for <ibis@eda.org>; Tue, 21 Dec 1999 14:54:06 -0500 (EST)
Received: from taurus.camarillo.viewlogic.com (taurus.camarillo.viewlogic.com [139.181.194.20])
	by mailhost.viewlogic.com (8.8.6/8.8.7) with ESMTP id OAA05741
	for <ibis@eda.org>; Tue, 21 Dec 1999 14:54:05 -0500 (EST)
Received: from f22.viewlogic.com (f22.camarillo.viewlogic.com [139.181.194.48])
	by taurus.camarillo.viewlogic.com (8.9.3/8.9.3) with SMTP id LAA13116
	for <ibis@eda.org>; Tue, 21 Dec 1999 11:54:00 -0800 (PST)
Received: by f22.viewlogic.com (SMI-8.6/SMI-SVR4)
	id LAA02909; Tue, 21 Dec 1999 11:54:40 -0800
Date: Tue, 21 Dec 1999 11:54:40 -0800
From: guy@camarillo.viewlogic.com (Guy de Burgh)
Message-Id: <199912211954.LAA02909@f22.viewlogic.com>
To: ibis@eda.org
Subject: EIA IBIS Open Forum Meeting Minutes - 12/17/99


DATE: 12/21/99

SUBJECT: 12/17/99 EIA IBIS Open Forum Meeting Minutes

VOTING MEMBERS AND 1999 PARTICIPANTS LIST:
3Com                           Roy Leventhal*
Applied Simulation Technology  Raj Raghuram*, Norio Matsui, Neven Orhanovic,
                               Fred Ballesteri*
Avanti                         Nikolai Bannov
Cadence Design                 Mike LaBonte*, Todd Westerhoff
Cisco Systems                  Syed Huq*
Compaq                         Bob Haller*, Steve Coe, Shafir Rahman,
                               Maher Elasad, Peter LaFlamme, Doug Burns
Cypress                        (Rajesh Manapat)
EMC Corporation                Fabrizio Zanella, Alex Nosovitski, Shan Haq
Fairchild Semiconductor        [Peter LaFlamme], Craig Klem, Graham Connolly,
                               Christian Klein*
H.A.S. Electronics             (Haruny Said)
Hewlett Packard (EEsof, etc.)  Paul Gregory, Henry Wu
HyperLynx (& Pads Software)    Matthew Flora*, Kellee Crisafulli*, 
                               Lynne Green, John Angulo*, Gene Garat, 
                               Robin Edwards
IBM                            Greg Edlund, Michael Cohen*, Praven Patel,
                               Paul Clouser
Incases                        Olaf Rethmeier, Werner Rissiek, David Eagles,
                               Wilhelm Arnoldi, Ulrich Losch
Intel Corporation              Stephen Peters*, Arpad Muranyi*, Frank Kern,
                               Martin Chang, Dave Moxley, Kerry Nelson,
                               Jeff Day, Richard Mellitz, Peter Liou,
                               Will Hobbs, Henri Maramis
LSI Logic (Symbios Logic)      Scott King
Mentor Graphics                Bob Ross*, Mohamed Mahmoud, Sherif Hammad,
                               Jean Oudinot, Markku Kukkanen, Martin Groeber,
                               Karine Loudet, Hisham Gamal, Evgeny Wasserman,  
                               Tom Dagostino, Mohamed Nasef
Mitsubishi                     (Tam Cao)
Motorola                       Ron Werner*
National Semiconductor         Milt Schwartz*
North East Systems Associates  Edward Sayre, Michael Baxter, Kathy Breda,
                               Ed Sayre III, Jinhua Chen
NEC                            (Hiroshi Matsumoto)
Nortel Networks                Martin Hall (& at Viewlogic), Calvin Trowell,
                               Ross Pryor
Philips Semiconductor          Todd Andersen, Peter Christiaans
Quantic EMC                    (Mike Ventham)
Siemens                        Bernhard Unger, Christian Mitschke, 
                               Manfred Maurer, Peter Kaiser, Wolfram Meyer,
                               Gerald Bannert, Harmut Ibowski, Katja Zuleeg,
                               Hans Pichlmaier, Eckhard Lenski, Kortheuer Udo,
                               Christian Sporrer
SiQual                         Scott McMorrow
Texas Instruments              Jean-Claude Perrin*, Shankar Balasubramaniah,
                               Ramzi Ammar, Thomas Fisher
Time Domain Analysis Systems   Dima Smolyansky*, Steven Corey
Viewlogic Systems              Chris Rokusek, Guy de Burgh*, Cary Mandel,
                               (Jon Powell)
VeriBest (Mentor Graphics)     [Ian Dodd]
Via Technologies               (Weber Chuang)
VLSI Technology (Philips)      D.C. Sessions*

OTHER PARTICIPANTS IN 1999:
3Dfx Interactive               Ken Wu
Actel Corporation              Silvia Montoya
Alcatel                        Steven Criel
Analytical Edge                Robert Easson
Applied Microelectronics       Brian Sanderson
BMW                            Friedrich Haslinger
Bogatin Enterprise             Eric Bogatin
Bosch Telecom                  Detlef Wolf
Celestica                      Danny Da Silva
Dynamics Research Corporation  Mike Walsh
ECI Telecom                    Daniel Adar
EIA                            [Patti Rusher], Cecilia Fleming*,
                               Dan Heinemeier 
Electronique                   Catherine Gross
EFM Consulting                 Ekkehard Miersch
FCI                            John Ellis
Foxcomm                        Jeff Walden
General DataComm               Laurence Michaels
High Design Technology         Razvan Ene
Hitachi ULSI                   Hideki Fukuda
Infineon                       Thomas Latzel
Intracon Design                Mike Osmond
KAW                            Shinichi Maeda
Litton Systems                 Robert Bremer
Lucent                         Jason Pritchard
Matsushita                     Atsuji Itoh
Molex Incorporated             Gus Panella
Newbridge Networks             Bruce Carlile
Oce Printing Systems           Ernst Deiringer
Praegitzer Design              Rick Newell, Paul Galloway, Joe Socha
Rockwell Collins               Susan Tweeton, Ron Hau
Rode Consulting                Chris Rode
Samsung                        Jung-Gun Byun, Cheol-Seung Choi
Shindengen                     Tsuyoshi Horigome
Signals & Systems Engineering  Tom Hawkins
STMicroelectronics             Fabrice Boissieres, Philippe LeFevre
Stratus                        Keith Vieira
StorageTek                     Nick Krull
Sun Microsystems               Victor Chang Kevin Ko, Greg Fitzgerald,
                               Nick LaPlaca
Tektronix                      Tom Brinkoetter
Teradyne                       Mikhail Khusid
VDOL                           Robert Novosel
Xilinx                         Susan Wu
(Unaffiliated, Retired)        Bruce Wenniger


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

Upcoming Meetings:  The bridge numbers for future IBIS teleconferences are as
follows:
  
  Date                Bridge Number    Reservation #    Passcode
  January 14, 2000    (916) 356-9200   5-169351         4378912
  January 31, 2000 - DesignCon 2000 IBIS Summit Meeting (No Bridge)

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

NOTE: "AR" = Action Required.

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

INTRODUCTIONS AND MEETING QUORUM
Bob Ross started the meeting and stated that there were the required number
of companies present to establish a quorum.


MEMBERSHIP UPDATE AND TREASURER'S REPORT
Bob Ross reported that 3Com has officially joined the EIA IBIS Open Forum
making the end of the year membership at 33.

Cecilia Fleming reported that invoices for year 2000 membership have been
mailed.


REVIEW OF MINUTES AND AR'S
Bob Ross corrected the attendee list in the December 3, 1999 Minutes to 
include Fred Ballesteri and not include Bob Haller.  Bob also made some 
format improvements and other minor changes to avoid line wrap in printing.

The December 3, 1999 IBIS Open Forum Meeting Minutes were approved with the
above changes.

The AR's will be discussed during the meeting.


MISCELLANY/ANNOUNCEMENTS
Bob Ross stated that these Minutes contain the final 1999 participation list.
Similarly in any previous year, the last minutes of that year contain the 
participation list for that year.  The next minutes will start a new list
of year 2000 participation.


PRESS AND WEB PAGE UPDATES
Syed Huq reported a Compaq logo update on the Poster and some minor roster
changes on the Poster and IBIS Roster Listing links of the official IBIS
Home page.

Bob Ross reported that DesignCon2000 has a presentation by Syed Huq on
"Solving SI Issues with IBIS Models in High-Speed Applications."


NEW MODELS AVAILABLE, LIBRARY UPDATE
Bob Ross reported that Jon Powell plans to do some updates to the Models
link of the IBIS Home Page over Christmas vacation.  (Send updates to him at 
the address at the end of the Minutes.)


OPENS FOR NEW ISSUES
None


INTERNATIONAL/EXTERNAL PROGRESS
- IEC 62014-1 (IBIS Version 3.2) - Cecilia Fleming is still waiting for word
on the formal ratification of IBIS Version 3.2 as IEC 62104-1.

- pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits
(IMIC) - Bob Ross had no further report and repeated from last meeting that a
Version 1.2 has been posted for review with a deadline of December 25, 1999.
Note added after the meeting: the link to the document has been moved and is
now located at the bottom of:

  http://tsc.eiaj.or.jp/eds/iopg.htm

- IEC PWI 93-1 Models of Integrated Circuits for EMI Behavioral Simulation
(formerly designated as IEC 93/67/NP IBIS and EMC Simulation) - Jean-Claude
Perrin reported that a document is still in preparation.  He will request
Bob Ross to review it, when available.

- JC-16.2 Subcommittee: Modeling and Test - Bob Ross reported that the D.C.
Sessions is the new Chair of JEDEC JC-16 and wants to work closely with the
IBIS Open Forum.


DESIGNCON 2000 IBIS SUMMIT PLANNING
Bob Ross stated that the IBIS Summit meeting is being held on Monday,
January 31, 2000 in Santa Clara, California.  The IBIS Open Forum is listed 
again as an Associate Sponsor of DesignCon 2000 which means that DesignCon
is providing the meeting room and refreshments and also booth space.
National Semiconductor is sponsoring the luncheon.

Milt Schwartz reported that has sent out the first announcement.  He has 
received about 5 responses so far, and about 10 people at the meeting
indicated that they plan to attend.  So it looks like we are on track for 
about 50 participants.  We will send out another notice in early January.

The program is being formed and may (tentatively) include these topics:

  Lynne Green -  "Model Design: Tables and Equations"
  Donald Telium  -  "Input Receiver Modeling"
  Gus Panella -   "Connector Model Specification"
  Bob Haller/Greg Edlund - "Accuracy Specification"
  Stephen Peters - "Discussion on the Future of IBIS"

Jon Powell is handling the IBIS booth and logos.  Also Bob Haller may have
and Accuracy board demonstration.


DATE2000 IBIS SUMMIT PLANNING
Bob Ross reported that Viewlogic has joined Incases and Mentor Graphics as
co-sponsors.

Bob reviewed that the DATE2000 IBIS Summit meeting associated with the
Design Automation and Testing in Europe conference is still planned to be 
held in Paris, France on Friday, March 31, 2000.  The meeting will end early
in the afternoon to allow attendees to fly back that evening. The PCB
Symposium is scheduled for Thursday, March 30, 2000.


COOKBOOK STATUS
Stephen Peters had no report.


IBIS MODEL REVIEW COMMITTEE DISCUSSION
No new models.


S2IBIS3 PROPOSAL DISCUSSION
Bob Ross opened the discussion by summarizing the previous meeting discussion. 
The question raised was whether the IBIS Open Forum should fund the 
development of a s2ibis3 utility which will compete commercial utilities.  
A decision is needed to before moving forward to get bids on doing the 
project based on the recently issued requirements document.

The s2ibis and s2ibis2 projects were done at North Carolina State University
under DARPA and private funding.  The purpose was to seed the development
of IBIS Models.  The utility was a prototype and was never was intended to be
of commercial quality.  In fact, it was turned over to the IBIS Open Forum
for support since the student developers could not provide the support.
Later in the meeting, Kellee Chrisafulli shared historical background that he 
originally pushed for the idea of a automatic Spice to IBIS translation 
utility in the IBIS Committee that initiated the project.

Bob stated some of the arguments regarding funding advanced at the last 
meeting:

Pro:

  The s2ibis freeware was first and is used by many developers
  The IBIS Open Forum has an obligation to maintain the utility
  This will improve the quality of models since it is widely used
  Freeware does not hurt commercial tools (e.g., Berkeley Spice)
  Helps promote IBIS Version 3.2
  This is really a bug fix project that extends to IBIS Version 3.2

Con:

  We already have rejected a Tektronix proposal with commercial conflicts
  The IBIS Open Forum actually supports commercial solutions
  This may be very expensive
  Active promotion of free tools is bad for commercial tools
  It is not fair to commercial vendors who have already invested the time and
    money, and then to user similar ideas
  The IBIS Committee would be better served to provide enticements to
    commercial vendors to improve their tools

  Also added: 
  The commercial product was introduced at DesignCon99 before the Spice to
    IBIS Committee was formed
  The IBIS Open Forum should have started the program earlier (before the
    commercial announcement)

Bob then asked for any more discussion.  Not all of the points are captured
here.

Kellee Chrisafulli argued that the IBIS Open Forum initiated the s2ibis
projects and that it was appropriate and relevant to advance it.  Furthermore,
he argued that deferring to one vendor's implementation gave that vendor
a monopoly.

Matthew Flora was concerned about the extent that the s2ibis3 committee used
the commercial implementation as the basis of the proposal.  Michael Cohen
clarified that the improvements were made without knowing the details of the
commercial implementation.  However, there was visibility of the IBIS Center 
Utility internal to Intel and the GUI from Cadence.  The main intent was to 
provide bug fixes.

Arpad Muranyi was concerned about any possible patent protection.  Bob did
not think this was a problem.

Stephen Peters was concerned that the project implies rewriting the code
versus just fixing it.   There was more of a flavor of a new project than
just a bug fix.

Raj Raghuran pointed out that the IBIS Open Forum did not actually fund the
original projects.  Kellee indicated that it might have done so if other
funding was not available.  There was some discussion on how s2ibis3
funding is similar or different than ibischk3 funding and whether the s2ibis3
utility is crucial to model development and promoting IBIS Version 3.2.

Ron Werner pointed out that EIA Committees can fund proof of concept tools, 
but should defer to commercial tools.

Arpad argued that the enhancements will give a better tool to the users and
will make the production of better IBIS models possible.  

Kellee and Raj discussed from different points of view that the market for
a commercial s2ibis3 tools is small.  Without the s2ibis3 utility, one vendor
could dominate.  However, because of the small market, a free tool could
stifle any commercial entry.  Commercial competition in even a small market
is possible and healthy.  Bob indicated that some company model development
services provide a different type of commercial competition.

Kellee suggested that the IBIS Home Page provide a link to the commercial
utility.  Bob stated that we do not promote commercial products.  However,
the companies can provide information from Poster page link and also give 
some general descriptions in the Roster page link.

Raj presented the analogy that if the IBIS Open Forum were considering
funding a free reference IBIS Simulator that competed with commercial 
simulators, there would be objection.  A reference simulator would 
"standardize" consistent operation and would be competitive to the higher 
cost commercial solutions that exist.  The relevance and critical need for 
such an IBIS simulator is similar to the s2ibis3 project needs.

Bob clarified that a vote not to fund the work does not prevent non-funded
volunteer work to fix or improve the existing utility and offer it to the
community.

Bob Ross called for a vote on whether the IBIS Open Forum should move forward
and ask for bids on the s2ibis3 development that would require EIA IBIS Open 
Forum funding.

The motion was defeated by a vote of 4 Yes, 7 No and 3 Abstaining.  (The
number of abstentions is corrected to 4 after the meeting.)

Michael Cohen disbanded the s2ibis3 sub-committee and thanked the participants 
for their fine work in drafting the requirements specification.  Others also 
thanked the sub-committee for their work.


CONNECTOR PROPOSAL REVIEW
In the remaining time, Bob Ross invited some further discussion on the 
Connector Specification.  Bob stated that he had become more familiar with the
document, but did not have time to write comments, as previously intended.
Arpad Muranyi had just issued some comments.

Bob provided a document overview.  Out of the 33 pages, about 6 pages are 
devoted to header and syntax rules similar those in the IBIS Standard, 12 
pages describe connector model keywords, and about 15 pages define the
matrices and swath matrix concept.

Bob asked Kellee Chrisafulli to discuss and clarify the swath matrix.  Kellee
indicated that it is intended to provide a more compact, but possibly less 
accurate description based on expanding a small representative section.  The 
connector vendors needed this capability because they did not intend to 
separate models for each of the many pin configurations for each connector.  
Outer edge columns or rows were intended to be simulated with paths
terminated by a specified [Cn_Z] impedance to approximate the surrounding
environment.  

Mike LaBonte commented the [Cn_Grid_Swath] keyword was more general and
eliminated the need for [Cn_Horizontal_Swath] and [Cn_Vertical_Swath]
keywords.  It would help implementors to have fewer choices.  Kellee stated
that there were additional reasons for the other keywords.

Kellee also noted that a complete physical representation of the connector
is possible without using the swath matrix approach.

Arpad Muranyi commented that it would be helpful to have a syntax map
diagram to help sort out the syntax details and rules in the document.

Bob ended the discussion to allow some comments regarding the next Agenda
item.


IBIS FUTURES (IBIS-X, API, BIRDxx)
Stephen Peters summarized that there has been recent reflector 
discussion with good ideas.  The range of proposals include formalized
Spice-like language to application program interface (API).  He commented
that he approached the problem by considering a high pin count component from 
a net centric point of view with drivers and receivers on the nets.  With 
such an approach, the enhanced model would handle details including package
details and pin coupling better. 

Arpad Muranyi stated that we need more time to discuss this subject.  Bob Ross
stated that this topic will be moved ahead of the Connector Specification
discussion in the next meeting Agenda.


NEXT MEETING:
The next teleconference meeting will be on Friday, January 14, 2000 from
8:00 AM to 10:00 AM.

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

IBIS CHAIR: Bob Ross (503) 685-0732, Fax (503) 685-4897
            bob_ross@mentor.com
            Modeling Engineer, Mentor Graphics
            8005 S.W. Boeckman Road, Wilsonville, OR 97070

VICE CHAIR: Stephen Peters (503) 264-4108, Fax: (503) 264-4515
            sjpeters@ichips.intel.com
            Senior Hardware Engineer, Intel Corporation
            M/S JF1-209
            2111 NE 25th Ave. 
            Hillsboro, OR 97124-5961

SECRETARY:  Guy de Burgh (805) 988-8250, Fax: (805) 988-8259
            gdeburgh@viewlogic.com
            Senior Manager, Viewlogic Systems
            1369 Del Norte Rd.
            Camarillo, CA 93010-8437

LIBRARIAN:  Jon Powell (805) 988-8250, Fax: (805) 988-8259
            jpowell@viewlogic.com
            Senior Scientist, Viewlogic Systems
            1369 Del Norte Rd.
            Camarillo, CA 93010

WEBMASTER:  Syed Huq (408) 525-3399, Fax: (408) 526-5504
            shuq@cisco.com
            Signal Integrity Engineer, Cisco Systems
            170 West Tasman Drive
            San Jose, CA 95134-1706

POSTMASTER: Matthew Flora (425) 869-2320, Fax: (425) 881-1008
            mbflora@hyperlynx.com
            Senior Engineer, HyperLynx, Inc.
            114715 N.E. 95th Street
            Redmond, WA 98052
 
This meeting was conducted in accordance with the EIA Legal Guides and EIA
Manual of Organization and Procedure.

The following e-mail addresses are used:

  ibis-request@eda.org
      To join, change, or drop from either the IBIS Open Forum Reflector
      (ibis@eda.org), the IBIS Users' Group Reflector (ibis-users@eda.org)
      or both.  State your request.

  ibis-info@eda.org
      To obtain general information about IBIS, to ask specific questions
      for individual response, and to inquire about joining the EIA-IBIS
      Open Forum as a full Member.

  ibis@eda.org
      To send a message to the general IBIS Open Forum Reflector.  This
      is used mostly for IBIS Standardization business and future IBIS
      technical enhancements.  Job posting information is not permitted.

  ibis-users@eda.org
      To send a message to the IBIS Users' Group Reflector.  This is 
      used mostly for IBIS clarification, current modeling issues, and
      general user concerns.  Job posting information is not permitted.

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

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

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

  http://www.eia.org/eig/ibis/ibis.htm

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

From owner-ibis  Thu Dec 23 12:21:03 1999
Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA05858 for <ibis@eda.org>; Thu, 23 Dec 1999 12:21:02 -0800 (PST)
Received: from xboibrg1.boi.hp.com (xboibrg1.boi.hp.com [15.56.8.167])
	by atlrel2.hp.com (Postfix) with ESMTP id 606D77E8
	for <ibis@eda.org>; Thu, 23 Dec 1999 15:20:13 -0500 (EST)
Received: by xboibrg1.boi.hp.com with Internet Mail Service (5.5.2650.21)
	id <Y8AT2C7X>; Thu, 23 Dec 1999 13:20:13 -0700
Message-ID: <85501B062BABD211A57E00A0C9E95C83031F0538@xsj01.sj.hp.com>
From: "LOO,JOHN (HP-SanJose,ex1)" <john_loo@agilent.com>
To: "'ibis@eda.org'" <ibis@eda.org>
Subject: IBIS Questions
Date: Thu, 23 Dec 1999 13:16:42 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01BF4D83.1DF81D7C"

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

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

Hi,

I had several questions regarding IBIS.

1) Is IBIS able to model SSTL2 and SSTL3?
2) Our company has created I/Os that are proprietary.  They are 
	differential.  They also need to be AC coupled.  As a result, 
	series capacitors must be placed between the driver and receiver.
	Our I/Os are designed to drive and receive A.C. PECL signals.  Can
	IBIS be used to model these I/Os? The D.C. levels of our drivers
	are not PECL levels. 
3) Can't IBIS model any I/O since it just utilizes I-V curves?  Is
	the question regarding generating IBIS models just a question
regarding
	how many I-V tables need to be generated and the loading conditions
	when generating the "Rising and Falling Waveform"?  Is this why IBIS
	can support only certain I/Os (TTL, ECL, etc).
4) Isn't the "Ramp" data and the "Rising and Falling Waveform" redundant?
	Aren't both used to determine rise and fall times?
5) Since IBIS uses I-V curves, can it model transient or hysteresis effects
of  
	drivers and receivers?  For example, if a driver initially drives
	6 ma at 2 volts (logic high).  After the driver stabilizes at the
logic
	high (2 volt), then it drives .05 ma.  It seems IBIS can't model
this 
	type of driver.  Is this true?  I assume that is why all packaging
elements
	(capacitors and inductors) must be separated from the output driver.

6) Are there any good books or documents on IBIS, how it works, and how to
create accurate IBIS
	models?
7) Is there anything preventing IBIS from accurately modelling high speed
circuits (rise/fall 
	times=100 ps)?
   	 
Best Regards,

John Loo
High Speed I/O PHY Products
408 435 6730
john_loo@hp.com


------_=_NextPart_000_01BF4D83.1DF81D7C
Content-Type: application/octet-stream;
	name="John Loo (E-mail).vcf"
Content-Disposition: attachment;
	filename="John Loo (E-mail).vcf"

BEGIN:VCARD
VERSION:2.1
N:Loo;John;;;
FN:John Loo (E-mail)
ORG:Hewlett-Packard;
TITLE:Applications Engineer
TEL;WORK;VOICE:(408) 435-6730
ADR;WORK:;;;;;;
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:, =0D=0A
EMAIL;PREF;INTERNET:john_loo@hp.com
REV:19990416T220011Z
END:VCARD

------_=_NextPart_000_01BF4D83.1DF81D7C--
From owner-ibis  Mon Dec 27 16:14:16 1999
Received: from hebe.or.intel.com (hebe.or.intel.com [134.134.248.4]) by server (8.8.5/8.8.3) with ESMTP id QAA00247 for <ibis@eda.org>; Mon, 27 Dec 1999 16:14:09 -0800 (PST)
Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200])
	by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.11 1999/11/10 17:27:15 spurcell Exp $) with ESMTP id NAA28152;
	Mon, 27 Dec 1999 13:14:50 -0800 (PST)
Received: from xtg801.pdx.intel.com (xtg801.pdx.intel.com [134.134.114.35])
	by ichips-jf.jf.intel.com (8.9.1a/8.9.1/d: internal.m4,v 1.2 1998/11/09 19:18:37 iwep Exp iwep $) with ESMTP id NAA04632;
	Mon, 27 Dec 1999 13:04:06 -0800 (PST)
Received: from ichips.intel.com (localhost.pdx.intel.com [127.0.0.1])
	by xtg801.pdx.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) with ESMTP id MAA12271;
	Mon, 27 Dec 1999 12:45:45 -0800 (PST)
Message-Id: <199912272045.MAA12271@xtg801.pdx.intel.com>
X-Mailer: exmh version 2.0delta 6/3/97
To: "LOO,JOHN (HP-SanJose,ex1)" <john_loo@agilent.com>
cc: "'ibis@eda.org'" <ibis@eda.org>
Subject: Re: IBIS Questions 
In-reply-to: Your message of "Thu, 23 Dec 1999 13:16:42 MST."
             <85501B062BABD211A57E00A0C9E95C83031F0538@xsj01.sj.hp.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 27 Dec 1999 12:45:44 -0800
From: Stephen Peters <sjpeters@ichips.intel.com>


Hello John:

   My comments are below.  

  Regards,
  Stephen Peters
  Intel Corp.


> Hi,
> 
> I had several questions regarding IBIS.
> 
> 1) Is IBIS able to model SSTL2 and SSTL3?
> 2) Our company has created I/Os that are proprietary.  They are 
> 	differential.  They also need to be AC coupled.  As a result, 
> 	series capacitors must be placed between the driver and receiver.
> 	Our I/Os are designed to drive and receive A.C. PECL signals.  Can
> 	IBIS be used to model these I/Os? The D.C. levels of our drivers
> 	are not PECL levels. 

I'm not real familiar with A.C. coupled P/ECL(?), but as long as you can 
extract DC I/V curves for both states and V/T curves switching into a 
representative non-reactive load, then you should be able to extract 
reasonable IBIS data that a simulator can then turn into a model.

> 3) Can't IBIS model any I/O since it just utilizes I-V curves?  Is
> the question regarding generating IBIS models just a question
> regarding how many I-V tables need to be generated and the loading conditions
> when generating the "Rising and Falling Waveform"?  Is this why IBIS
> can support only certain I/Os (TTL, ECL, etc).

  Basicly, yes. Although, in fairness, IBIS can describe most any currently 
available I/O structure.

> 4) Isn't the "Ramp" data and the "Rising and Falling Waveform" redundant?
> 	Aren't both used to determine rise and fall times?

  The Ramp data was the used for specifying ramp times in IBIS ver 1.1 models 
but it has been superseded by the Rising and Falling Waveform data (for IBIS 
ver 2.1 and above).  "Ramp" is retained only for backwards compatibility.  If 
the Waveform data is available then most all simulators will choose this over 
the Ramp data as the Waveform data leads to a better model.

> 5) Since IBIS uses I-V curves, can it model transient or hysteresis effects
> of  drivers and receivers?  For example, if a driver initially drives
> 6 ma at 2 volts (logic high).  After the driver stabilizes at the
> logic	high (2 volt), then it drives .05 ma.  It seems IBIS can't model
> this 	type of driver.  Is this true?  I assume that is why all packaging
> elements(capacitors and inductors) must be separated from the output driver.
>

  Well, first I would say that if an IBIS data sheet contains I/V or V/T data 
that is non-monotonic, multi-valued, or otherwise 'ill-behaved', then I would 
not expect a simulator to turn that data into a usable model. However, given 
your description, it sounds like the driver above can be modeled by using the 
[Driver Schedule] keyword.  This keyword, in effect, allows one to switch in 
our out multiple I/V and V/T curves, and is included specifically to model 
drivers with multiple output stages (which is what it sounds like you have). 
This keyword is available in IBIS ver3.1.  Of course, your simulator must also 
support this keyword -- check with your vendor.

I'm not sure what you mean by the statement "all packaging elements must be 
separated fro the output driver"  Are you referring to the on-die power and 
ground distribution network to the buffer and how gnd bounce and/or rail 
collapse effects the V/T curves?


> 6) Are there any good books or documents on IBIS, how it works, and how to
> create accurate IBIS models?

  The IBIS Cookbook is probably the most comprehensive guide available on 
making IBIS models -- it is available on the IBIS website at 
http://www.eia.org/eig/ibis/tools.htm (bottom of the page).  I also suggest 
contacting your simulation software vendor, especially is you have specific 
questions about how a particular keyword is used, or what data works best for 
a specific driver and application.

> 7) Is there anything preventing IBIS from accurately modeling high speed
> circuits (rise/fall times=100 ps)?

Well, depends on what your requirements are for 'accuaracy'.  As far as the 
basic behavioral description of a driver goes, I belive I/V and V/T 
descriptions can produce simulation results that are within the 10s of PS of 
detailed transistor level models.  However, there are other effects, external 
to the driver itself, that must be accounted for -- specifically SSO effects 
(i.e. power and ground inductance) and pin-to-pin coupling. Currently, IBIS 
does not supply the data required to model pin-to-pin coupling, and not all SI 
simulators support the inclusion of power and ground inductances/capacitance 
networks.  One approach is to include these effects by gardbanding the slow 
and/or fast corners of the model and/or including these effects as a separate 
line item in your timing budget, but (obviously) only you can determine if 
that is 'accurate enough'.


>    	 
> Best Regards,
> 
> John Loo
> High Speed I/O PHY Products
> 408 435 6730
> john_loo@hp.com
> 
> 

From owner-ibis  Tue Dec 28 14:12:55 1999
Received: from hebe.or.intel.com (hebe.or.intel.com [134.134.248.4]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA03942; Tue, 28 Dec 1999 14:12:55 -0800 (PST)
Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200])
	by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.11 1999/11/10 17:27:15 spurcell Exp $) with ESMTP id OAA13604;
	Tue, 28 Dec 1999 14:22:49 -0800 (PST)
Received: from xtg801.pdx.intel.com (xtg801.pdx.intel.com [134.134.114.35])
	by ichips-jf.jf.intel.com (8.9.1a/8.9.1/d: internal.m4,v 1.2 1998/11/09 19:18:37 iwep Exp iwep $) with ESMTP id OAA20534;
	Tue, 28 Dec 1999 14:12:05 -0800 (PST)
Received: from ichips.intel.com (localhost.pdx.intel.com [127.0.0.1])
	by xtg801.pdx.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) with ESMTP id NAA20648;
	Tue, 28 Dec 1999 13:53:29 -0800 (PST)
Message-Id: <199912282153.NAA20648@xtg801.pdx.intel.com>
X-Mailer: exmh version 2.0delta 6/3/97
To: ibis@eda.org, ibis-users@eda.org
Subject: BIRD 61.1
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 28 Dec 1999 13:53:28 -0800
From: Stephen Peters <sjpeters@ichips.intel.com>


Hello All:

  Apologies for the long delay, but here are the updates to the three
birds that deal with receiver characterization and specification.  For
details on the specific changes to each bird, look in the  ANALYSIS 
section at the bottom. 

  Regards,
  Stephen Peters
  Intel Corp.

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


                 Buffer Issue Resolution Document  (BIRD)


BIRD ID#:   61.1
ISSUE TITLE: Enhanced Characterization of Receivers
REQUESTOR: D.C Sessions (Philips), Richard Mellitz, Stephen Peters,
           Arpad Muranyi (Intel Corp)
DATE SUBMITTED: August 9, 1999, Dec 28, 1999
DATE ACCEPTED BY IBIS OPEN FORUM: 

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

STATEMENT OF THE ISSUE:  The current specification allows the user to 
describe the static Vinh and Vinl thresholds of a receiver.  However, these
parameters specify only the DC input thresholds at which the output of 
a receiver switches state.  They do not describe a digital logic receiver's
dynamic performance.  Dynamic performance includes such items as how a
device's setup or hold time varies with input overdrive, or how a receiver
behaves when an input waveform rings back into the area between Vinh and
Vinl.  In addition, the current specification does not support simulation
methodologies that rely on specifying the total delay from the input of an
output buffer to the output of the receiver.  This bird offers a way for the
user to specify a receiver's propagation delay and dynamic characteristics in
enough detail so that a simulation tool can model a receiver's response to
any arbitrary waveform.

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

STATEMENT OF THE RESOLVED SPECIFICATIONS:  

1) The following new keyword is defined, and is placed in the
specification just below the [Rising Waveform] and [Falling Waveform]
keyword descriptions

|=============================================================================
|      Keyword: [Receiver Delay]
|     Required: No
|   Sub-Params: Vth, Start_point, End_point, Slope
|  Description: This keyword specifies how the propagation delay of an 
|               input receiver varies as a function of input overdrive or 
|               input waveform slope.  
|
|  Usage Rules: The [Receiver Delay] keyword is followed immediately by the 
|               three subparameter names and their arguments. The Start_point
|               and End_point subparameters define the starting and ending 
|               voltage points of a linear ramp while the Slope parameter 
|               specifies the slope of that ramp.  Slope is given in units of 
|               volts per second (V/S).  The Vth subparameter is the ideal
|               input voltage at which the output of a receiver changes
|               state.  The value of the Start_point and End_point 
|               subparameters are always expressed as offsets from this 
|               voltage.  All four subparameters are required.
|
|               Subparameter Usage:
|               The intent of the subparameters is to specify a set of linear 
|               ramps that vary only in starting point, ending point, or 
|               slope.  Therefore, when assigning values to the subparameters,
|               two of the three subparameters must be assigned fixed values,
|               while the third subparameter uses as its argument the reserved 
|               word TABLE.  The use of the word TABLE indicates that this 
|               subparameter is the independent variable in the associated 
|               receiver delay table.  The subparameter that uses the TABLE 
|               argument must appear after the other two subparameters and 
|               before the receiver delay table.  
|
|               Numerical arguments are separated from their associated
|               subparameter by an equals sign (=); white space around the 
|               equals sign is optional.  The TABLE argument is separate
|               from its associated subparameter by white space.
|
|               Receiver Delay Table:
|               Following the subparameters is the receiver delay table itself.
|               This table consists of four columns.  The first column lists
|               either the starting or ending offset from Vth or the slope
|               of the linear ramp (i.e. the independent variable as determined
|               by the subparameter with the TABLE argument). The second thru
|               fourth columns list the change in the receiver's propagation
|               delay. This "change in delay" is relative to the receiver's
|               delay when it is stimulated using the same overdrive and edge
|               rate conditions used to specify the device's setup and hold
|               times.  The delay columns are arranged in the standard typ, 
|               min, max format.  All four entries must be placed on the same
|               line and must be separated by at least one white space.  All
|               four columns are required.  However, data is required only for
|               the typical column. If minimum or maximum data is not available
|               use the reserved word NA.  Each receiver delay table is limited
|               to 100 rows and only one receiver delay table is allowed per
|               [Receiver Delay] keyword.  However, there are no restrictions
|               on the number of [Receiver Delay] keywords per [Model] keyword.
|               Note that the [Receiver Delay] keyword is not allowed unless
|               the Model_type of the [Model] is one of the Input or I/O
|               models types.
|
|               Use of INF as a Receiver Delay:
|               When building a receiver delay table the user may specify an 
|               input condition that does not result in the receiver's output 
|               changing state.  In that case, the receiver delay is considered
|               infinite, and the reserved word INF is used in the delay
|               column.  See the examples below.
|               
|               Other Notes:
|               It is expected that the user will provide enough [Receiver
|               Delay] keywords (i.e. characterization data) to allow a CAE 
|               tool to build a model of the input receiver.  It is expected
|               that at least four [Receiver Delay] keywords will be required;
|               two low to high going ramps and two high to low going ramps.
|               However, the exact number of ramps and there content is up
|               to the user and recommendations provided by the various
|               simulation vendors.
|
| An example table showing how receiver delay varies vs. overdrive.
| Note the use of the reserved word INF.  Also note that Start_point
| and End_point are expressed as offsets from the Vth parameter.
|
[Receiver Delay]
Vth = 1.5v
Start_point = -0.7v
Slope = 1v/1ns
End_point  TABLE
|variable      typ     min    max
-0.10          INF     7.0ns  INF
+0.00          INF     5.0ns  INF
+0.01          INF     3.0ns  10.0ns
+0.03          7.0ns   0.0ns  7.0ns
+0.05          2.0ns   0.0ns  1.0ns
+0.10          0.0ns   0.0ns  0.0ns
+0.20          0.0ns   0.0ns  0.0ns
+0.50          0.0ns   0.0ns  0.0ns
+0.60          0.1ns   0.1ns  0.1ns
+1.00         -0.2ns  -0.1ns -0.5ns
|
| A second table that characterizes receiver delay vs. the slope of the
| input waveform.
|
[Receiver Delay]
Vth = 1.5v
Start_point = -0.7v
End_point = +0.5v
Slope  TABLE
|variable      typ     min    max
0.05/1ns      -1.0   -3.5    -1.0
0.25/1ns      -0.75  -2.0    -0.05
0.50/1ns      -0.01  -0.5    -0.0
0.60/1ns       0.0    0.25    0.0
0.75/1ns       0.0    0.0     0.0
1.00/1ns       0.0    0.0     0.0
2.00/1ns      +0.5   +0.2    +1.0
|
|
|2)  Item 2 under General Syntax Rules and Guidelines is modified to include
|the following reserved words

   INF   - used when a data value is so large it is considered infinite
   TABLE - used to indicate that a subparameter's value(s) are part of a
           table.
*******************************************************************************

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:  This bird originated from
discussions held at the January '99 IBIS summit regarding the lack of a
way to accurately and realistically specify the input thresholds and 
dynamic performance of a digital logic receiver.  At the mid year '99 IBIS
summit D.C. Sessions, Stephen Peters, Richard Mellitz and Arpad Muranyi
agreed to meet to hammer out a proposal.  This bird is one of the results.
The technical basis of this bird derives from simulation work done by
Richard Mellitz.

Updates to 61.1:
  Added the Vth subparameter, and changed the definition of the Start_point 
and End_point parameters to be offsets from Vth.  Updated/corrected the
examples.

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

ANY OTHER BACKGROUND INFORMATION:



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






From owner-ibis  Tue Dec 28 14:16:46 1999
Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA03973; Tue, 28 Dec 1999 14:16:46 -0800 (PST)
Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200])
	by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.11 1999/11/10 17:27:15 spurcell Exp $) with ESMTP id OAA14536;
	Tue, 28 Dec 1999 14:15:57 -0800 (PST)
Received: from xtg801.pdx.intel.com (xtg801.pdx.intel.com [134.134.114.35])
	by ichips-jf.jf.intel.com (8.9.1a/8.9.1/d: internal.m4,v 1.2 1998/11/09 19:18:37 iwep Exp iwep $) with ESMTP id OAA20925;
	Tue, 28 Dec 1999 14:15:56 -0800 (PST)
Received: from ichips.intel.com (localhost.pdx.intel.com [127.0.0.1])
	by xtg801.pdx.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) with ESMTP id NAA20673;
	Tue, 28 Dec 1999 13:57:19 -0800 (PST)
Message-Id: <199912282157.NAA20673@xtg801.pdx.intel.com>
X-Mailer: exmh version 2.0delta 6/3/97
To: ibis@eda.org, ibis-users@eda.org
Subject: BIRD 63.1 -- Documentation of Setup and Hold conditions
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 28 Dec 1999 13:57:18 -0800
From: Stephen Peters <sjpeters@ichips.intel.com>


Hello All:

  Update to bird 63.

   Regards,
   Stephen Peters
   Intel Corp.

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

                Buffer Issue Resolution Document  (BIRD)

BIRD ID#:     63.1
ISSUE TITLE:  Documentation of Receiver Setup and Hold Timing Conditions
REQUESTOR:    D.C. Sessions (Philips), Stephen Peters, Richard Melitz,
              Arpad Muranyi (Intel Corp.)
DATE SUBMITTED:  Sept 8, 1999, Dec 27, 1999
DATE ACCEPTED BY IBIS OPEN FORUM:

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

STATEMENT OF THE ISSUE:  Currently, the edge rate and overdrive conditions
under which a receiver's data book setup and hold timings are specified are
not documented.  This bird provides a way for the model creator to document
those conditions in an IBIS file.

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

STATEMENT OF THE RESOLVED SPECIFICATIONS:

1) The following new keyword is defined and placed in the specification
just below the [Receiver Spec] keyword.

|=============================================================================
|      Keyword: [Tester Spec]
|     Required: No
|   Sub-Params: Tester_Vlow, Tester_Vhigh, Tester_Vth, Tester_Slew_Setup,
|               Tester_Slew_Hold
|  Description: The [Tester Spec] keyword documents the input overdrive
|               and tester slew rate conditions under which a device's
|               input setup and hold times are specified.  The subparameters
|               are defined as follows:
|
|               Tester_Vth is the point on the input waveform from 
|               which an receivers setup and hold time is referenced.  It is
|               usually the input voltage at which the output of a digital
|               logic receiver changes state.  Tester_Vth is used as the
|               reference voltage for the Tester_Vlow and Tester_Vhigh
|               parameters.
|
|               Tester_Vlow represents the starting voltage of the low-to-high
|               going waveform a tester uses when characterizing a receiver's
|               setup or hold time. It also represents the ending voltage of a
|               high-to-low going waveform.  Tester_Vlow is expressed as an
|               offset from Tester_Vth.
|
|               Tester_Vhigh represents the ending voltage of the low-to-high
|               going waveform a tester uses when characterizing a receiver's
|               setup or hold time. It also represents the starting voltage of
|               a high-to-low going waveform.  Tester_Vhigh is expressed as an
|               offset from Tester_Vth.
|
|               Tester_Slew_Setup is the tester waveform's slew rate at
|               which a receiver's setup time is specified.  For purposes of
|               this keyword, slew rate is defined as:
|
|                               Tester_Vhigh - (Tester_Vlow)
|         Slew Rate  = -------------------------------------------
|                        Time it takes to swing the above voltage
|
|               Tester_Slew_Setup must be expressed as an explicit ratio 
|               of voltage over time, and not reduced to a decimal number.
|
|               Tester_Slew_Hold is the tester waveform's slew rate at which
|               a receiver's hold time is specified.  Slew rate is defined
|               as above.  Tester_Slew_Hold must be expressed as an explicit
|               ratio of voltage over time, and not reduced to a decimal
|               number.
|
|
| Usage Rules:  The [Tester Spec] keyword is valid if the model type
|               includes any reference to input or I/O.  All subparameters
|               are required to be present.  When entering a value the
|               subparameter argument and the subparameter itself must
|               be separated by an equals sign (=).
|
|               Differential Receivers:
|               For a single ended receiver the numerical value of
|               Tester_Vth is specified with respect to 0v.  However, if
|               the [Tester Spec] keyword is describing a differential receiver
|               (i.e. is part of a [Model] statement that describes a pin
|               listed in the [Diff Pin] keyword), then the numerical value of
|               Tester_Vth is typically given as 0v.  Tester_Vlow and 
|               Tester_Vhigh are then assumed to represent the difference in
|               voltage between one input and the other.
|
|
| A basic 3.3v single ended receiver
Tester_Vth   = 1.5v
Tester_Vlow  = -1.0v
Tester_Vhigh = 2.5v
Tester_Slew_setup = 1v/ns
Tester_Slew_hold = 1v/ns
|
| A differential receiver
Tester_Vth = 0V
Tester_Vlow = -200mV
Tester_Vhigh = +200mV
Tester_Slew_setup = 1.2v/1ns
Tester_Slew_hold = 1.2v/1ns
|
|
*******************************************************************************

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:  Like it's companion BIRD #62,
this bird is an attempt to better specify and document a receiver's
functionality.  It follows the convention of the previous BIRDS in that
most of the parameter values are specified as an offset from a reference
voltage.  This technique supports both single ended and differential
receivers.

Note that there are separate slew rate entries for setup and hold time.  When
formulating this bird the authors were not sure if receiver hold time was
specified under different slew rate conditions than setup time.  Thus,
separate slew rate entries.  These two parameters can be collapsed into one
if further information indicates that this is not the case.

Updates for 63.1:
  Corrected "Tester_Skew" to "Tester_Slew" in the examples (typo
correction) and fixed up the Slew_rate equation by removing the
absolute value markers.  Changed Slew_rate so that it is expressed
as an explicit ratio and not as a decimal (following the convention of
[Ramp Rate]).  Clarified the meaning of Tester_Vth.  Finally, under 
"Differential Receivers:" changed the text to indicate that the numerical 
value of Tester_Vth is *typically* given as 0v rather than *must* be given 
as zero. 


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

ANY OTHER BACKGROUND INFORMATION: This BIRD is a direct result of a
request by the JEDEC JC-15 committee to the IBIS Open Forum to provide better
specification of receivers.  The basic form of this bird was discussed at
a meeting in July 1999 between DC Sessions of Phillips Corp. and Stephen
Peters, Richard Melitz and Aprad Muranyi of Intel Corp.

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



From owner-ibis  Tue Dec 28 14:14:26 1999
Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA03950; Tue, 28 Dec 1999 14:14:25 -0800 (PST)
Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200])
	by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.11 1999/11/10 17:27:15 spurcell Exp $) with ESMTP id OAA14232;
	Tue, 28 Dec 1999 14:13:34 -0800 (PST)
Received: from xtg801.pdx.intel.com (xtg801.pdx.intel.com [134.134.114.35])
	by ichips-jf.jf.intel.com (8.9.1a/8.9.1/d: internal.m4,v 1.2 1998/11/09 19:18:37 iwep Exp iwep $) with ESMTP id OAA20645;
	Tue, 28 Dec 1999 14:13:33 -0800 (PST)
Received: from ichips.intel.com (localhost.pdx.intel.com [127.0.0.1])
	by xtg801.pdx.intel.com (8.9.1a/8.9.1/d: client.m4,v 1.3 1998/09/29 16:36:11 sedayao Exp sedayao $) with ESMTP id NAA20659;
	Tue, 28 Dec 1999 13:54:56 -0800 (PST)
Message-Id: <199912282154.NAA20659@xtg801.pdx.intel.com>
X-Mailer: exmh version 2.0delta 6/3/97
To: ibis@eda.org, ibis-users@eda.org
Subject: BIRD 62.1
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 28 Dec 1999 13:54:56 -0800
From: Stephen Peters <sjpeters@ichips.intel.com>



Hello All:
  
  Here is the update to bird62.

   Regards,
   Stephen Peters
   Intel Corp.


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


                  Buffer Issue Resolution Document  (BIRD)
 
 BIRD ID#:      62.1
 ISSUE TITLE:   Enhanced Specification of Receiver Thresholds
 REQUESTOR:     DC Sessions (Philips), Stephen Peters, Richard Melitz,
                Arpad Muranyi (Intel Corp).
 DATE SUBMITTED:  Aug 24, 1999, Dec 28, 1999
 DATE ACCEPTED BY IBIS OPEN FORUM:
 
*******************************************************************************
*******************************************************************************
 
 STATEMENT OF THE ISSUE:  When specifying receiver input thresholds the current
 specification allows only the traditional DC derived Vinh and Vinl parameters.
 These two parameters are no longer adequate for describing receivers used for
 high speed designs.  This BIRD proposes four new input switching threshold
 parameters: Vinh_ac, Vinh_dc, Vinl_ac, Vinl_dc.  These parameters are
 referenced to an reference point Vth, and this reference is allowed to vary
 with variations in a supply.
 
*******************************************************************************
 
 STATEMENT OF THE RESOLVED SPECIFICATIONS:
 
 1) The following new keyword is defined and placed in the specification
 just below the [Model Spec] keyword.
 
|=============================================================================
|      Keyword: [Receiver Thresholds]
|     Required: No
|   Sub-Params: Vth, Vth_min, Vth_max, Vinh_ac, Vinh_dc, Vinl_ac, Vinl_dc,
|               Vth_sensitivity, Input_Ref_Supply
|  Description: The [Receiver Thresholds] keyword defines both a set of
|               receiver input thresholds as well as their sensitivity to
|               variations in a referenced supply.  The subparameters are
|               defined as follows:
|
|               Vth, Vth_min and Vth_max are the ideal input threshold voltage
|               at which the output of a digital logic receiver changes state.
|               Vth is the nominal input threshold voltage under the voltage,
|               temperature and process conditions that define 'typ'.  Vth_min
|               is the minimum input threshold voltage at 'typ' conditions
|               while Vth_max is the maximum input threshold voltage at 'typ'
|               conditions.
|
|               Vinh_ac is the voltage that a low-to-high going input waveform
|               must reach in order to guarantee that the receiver's output
|               has changed state.  In other words, reaching Vinh_ac is
|               sufficient to guarantee a receiver state change.  Vinh_ac is
|               expressed as an offset from Vth.
|
|               Vinh_dc is the voltage that an input waveform must remain
|               above (more positive than) in order to guarantee that a
|               receiver output will NOT change state.  Vinh_dc is expressed
|               as an offset from Vth.
|
|               Vinl_ac is the voltage that a high-to-low going input waveform
|               must reach in order to guarantee that the receiver's output
|               has changed state.  In other words, reaching Vinl_ac is
|               sufficient to guarantee a receiver state change.  Vinl_ac
|               is expressed as an offset from Vth.
|
|               Vinl_dc is the voltage that an input waveform must remain below
|               (more negative than) in order to guarantee that a receiver's
|               output will NOT change state.  Vinh_dc is expressed as a
|               offset from Vth.
|
|               Vth_sensitivity is a unitless number that specifies how Vth
|               varies with respect to the supply voltage defined by the
|               Input_Ref_Supply subparameter. Vth_sensitivity is defined
|               as:
|
|                                   change in input threshold voltage
|               Vth_sensitivity = ------------------------------------
|                                  change in referenced supply voltage
|
|               Vth_sensitivity must be entered as a whole number or
|               decimal, not as a fraction.
|
|               Input_Ref_Supply indicates which supply voltage Vth tracks;
|               i.e. it indicates which supply voltage change causes a change
|               in input threshold.  The legal arguments to this subparameter
|               are VOLTAGE_RANGE (the supply voltage defined by the
|               [Voltage Range] keyword), PULLUP_REF (the supply voltage
|               defined by the [Pullup Reference] keyword), or EXT (an
|               external voltage defined by the [External Reference] keyword).
|
|
| Usage Rules:  The [Receiver Thresholds] keyword is valid if the model type
|               includes any reference to input or I/O.  The Vinh_ac, Vinh_dc,
|               Vinl_ac, Vinh_dc and Vth subparameters are required and
|               override the Vinh, Vinl, Vinh+/- and Vinl+/- subparameters
|               declared under the [Model] or [Model Spec] keywords.  The
|               Vth_min, Vth_max, Vth_sensitivity and Input_Ref_Supply 
|               subparameters are optional.  However, if the Vth_sensitivity
|               subparameter is present then the Input_Ref_Supply 
|               subparameter must also be present.
|
|               Vth at Minimum or Maximum Operating Conditions:
|               As described above, the Vth_min and Vth_max subparameters
|               define the minimum and maximum input threshold values under
|               typical operating conditions.  There is no provision for
|               directly specifying Vth under minimum or maximum operating
|               conditions.  Instead, these values are calculated using
|               the following equation:
|
|      Vth(min/max) = Vth* + [(Vth_sensitivity) X (change in supply voltage)]
|
|               where Vth* is either Vth, Vth_min or Vth_max as appropriate,
|               and the supply voltage is the one indicated by the
|               Input_Ref_Supply subparameter.
|
|
|               Differential Receivers:
|               For a single ended receiver the numerical values of Vth,
|               Vth_min and Vth_max are specified with respect to 0v.
|               However, if the [Receiver Threshold] keyword is describing
|               a differential receiver (i.e. is part of a [Model] statement
|               that describes a pin listed in the [Diff Pin] keyword), then
|               Vth is typically assigned a value of zero volts and the 
|               Vth_min and Vth_max parameters are not used.  The values of 
|               Vinh_* and Vinl_* subparameters are still given as an
|               offset from Vth and become, in effect, the more traditional 
|               Vdiff.
|
| Examples:
|
| A basic 3.3v single ended receiver using only the required
| subparameters
|
Vth = 1.5v
Vinh_ac = +225mV
Vinh_dc = +100mV
Vinl_ac = -225mV
Vinl_dc = -100mV
|
|
| A single ended receiver using an external threshold reference.  In this
| case the input threshold is the external reference voltage so
| Vth_sensitivity equals 1.
|
Vth = 1.0v
Vth_sensitivity = 1
Input_Ref_Supply = EXT
Vinh_ac = +200mV
Vinh_dc = +100mV
Vinl_ac = -200mV
Vinl_dc = -100mV
|
|
| A fully specified single ended 3.3v CMOS receiver
|
Vth = 1.5v
Vth_min = 1.45v
Vth_max = 1.53v
Vth_sensitivity = 0.45
Input_Ref_Supply = VOLTAGE_RANGE
Vinh_ac = +200mV
Vinh_dc = +100mV
Vinl_ac = -200mV
Vinl_dc = -100mV
|
|
| A differential receiver
|
Vth = 0.0v
Vinh_ac = +50mV
Vinh_dc = +25mV
Vinl_ac = -50mV
Vinl_dc = -25mV

2) The following new keyword is defined and place in the specification
following the [GND Clamp Reference] keyword
|=============================================================================
|      Keyword: [External Reference]
|     Required: Yes, if a receiver's input threshold is determined by an
|               external reference voltage
|  Description: Defines a voltage source that supplies the reference voltage
|               used by a receiver for its input threshold reference.
|  Usage Notes: Provide actual voltages (not percentages in the typ, min max
|               format.  "NA" is allowed for the min and max values only.
|-----------------------------------------------------------------------------
| variable              typ          min           max
[External Reference]    1.0v         0.95v        1.05v

3)  Under section 2 of General Syntax Rules and Guidelines the following
words are added to the list of reserved words.

EXT   -  A reference to a voltage defined by the [External Reference] Keyword
VOLTAGE_RANGE - A reference to a voltage defined by the [Voltage Range] keyword
PULLUP_REFERENCE - A reference to a voltage defined by the [Pullup
Reference] keyword

******************************************************************************
 
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:  This proposal follows the
recommendations of the JC-15 committee for specifying SDRAM inputs.

Update for 62.1:
  Specified exactly which [Model] and [Model Spec] parameters are
overridden by [Receiver Threshold] and changed the wording of the
"Differential Receivers:"  to indicate that the numerical 
value of Vth is *typically* assigned a value of 0v rather than 
*must* be assigned a value of zero.
 
******************************************************************************

ANY OTHER BACKGROUND INFORMATION: This BIRD is a direct result of a
request by the JEDEC JC-15 committee to the IBIS Open Forum to provide better
specification of receivers.  The basic form of this bird was discussed at
a meeting in July 1999 between DC Sessions of Phillips Corp. and Stephen
Peters, Richard Melitz and Aprad Muranyi of Intel Corp.

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



From owner-ibis  Thu Dec 30 15:16:49 1999
Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id PAA12048 for <ibis@eda.org>; Thu, 30 Dec 1999 15:16:48 -0800 (PST)
Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F)
	id PAA14499; Thu, 30 Dec 1999 15:15:27 -0800 (PST)
Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R)
	id PAA24314; Thu, 30 Dec 1999 15:15:26 -0800 (PST)
Sender: bob_ross@mentorg.com
Message-ID: <386BE78E.CC12CFBE@mentor.com>
Date: Thu, 30 Dec 1999 15:15:26 -0800
From: Bob Ross <bob_ross@mentorg.com>
X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: ibis@eda.org
Subject: IBIS - Connector Tree Diagram
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

To All:

To help read and review the Connector Specification, I have a draft tree
diagram of the keywords and subparameters for the .ibiscnn File.  For
comparison, the tree diagrams for the .pkg and .ebd files are also 
included at the end.

The Connector Specification lists the matrix formats: Banded_matrix,
Sparse_matrix, Full_matrix, and Diagonal_matrix as both keywords and
subparameters.  I have diagrammed them as subparameters, consistent with
existing IBIS documentation.

Bob Ross
Mentor Graphics

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



          (Unofficial) Tree Diagram for IBIS Connector Specification
                               Version 0.92
                                 12/30/99
           
		
  (m) indicates that keyword or subparameter may occur multiple times.

  (ml) indicates that keyword may occur multiple times at any location.

  * indicates that enumerated selections for the keyword or subparameter
  are provided at the end (other than possible reserved word NA and NC
  entries).


.ibiscnn FILE
-------------
  |-- File Data Section
  |   -----------------
  |     |-- [IBIS_Cn_Model_Ver]
  |     |-- [Comment Char] (ml)
  |     |-- [File Name]
  |     |-- [File Rev]
  |     |-- [Date]
  |     |-- [Source]
  |     |-- [Notes]
  |     |-- [Disclaimer]
  |     |-- [Copyright]
  |     |-- [Manufacturer]
  |     |-- [Web_Site]
  |     |-- [Email]
  |     |-- [Redistribution] *
  |
  |-- [Begin_Cn_Model_Family]
  |   -----------------------
  |     |-- [Begin_Cn_Family_Description]
  |     |     |-- [End_Cn_Family_Description]
  |     |-- [Begin_Cn_Model_List] *
  |     |     |-- [End_Cn_Model_List]
  |     |
  |     |-- [Begin_Cn_Model] * (m)
  |     |    ---------------
  |     |     |-- [Begin_Cn_Model_Description]
  |     |     |     |-- [End_Cn_Model_Description]
  |     |     |-- [Cn_Number_of_Conductors]
  |     |     |-- [Cn_Columns_of_Pins] *
  |     |     |-- [Cn_Rows_of_Pins]
  |     |     |-- [Begin_Cn_Auto_Map] *
  |     |     |     |-- [End_Cn_Auto_Map]
  |     |     |-- [Begin_Cn_Swath]
  |     |     |   ----------------
  |     |     |     |-- [Cn_Z]
  |     |     |     |-- [Cn_Horizontal_Swath]
  |     |     |     |-- [Cn_Vertical_Swath]
  |     |     |     |-- [Cn_Grid_Swath]
  |     |     |     |-- [End_Cn_Swath]
  |     |     |-- [End_Cn_Model]
  |     |
  |     |-- [Begin_Cn_Pin_Map] (m)
  |     |     |-- [End_Cn_Pin_Map]
  |     |
  |     |-- [Begin_Cn_Phy_Map] (m)
  |     |     |-- [Row] (m)
  |     |     |-- [End_Cn_Phy_Map]
  |     |
  |     |-- [Begin_Cn_Section] (m)
  |     |   ------------------
  |     |     |-- [Resistance Matrix]      Banded_matrix, Sparse_matrix,
  |     |     |                            Full_matrix, Diagonal_Matrix
  |     |     |   -------------------     
  |     |     |     |-- [Bandwidth]
  |     |     |     |-- [Row] (m)
  |     |     |-- [Inductance Matrix]      Banded_matrix, Sparse_matrix,
  |     |     |                            Full_matrix, Diagonal_Matrix
  |     |     |   -------------------     
  |     |     |     |-- [Bandwidth]
  |     |     |     |-- [Row] (m)
  |     |     |-- [Capacitance Matrix]     Banded_matrix, Sparse_matrix,
  |     |     |                            Full_matrix, Diagonal_Matrix
  |     |     |   --------------------    
  |     |     |     |-- [Bandwidth]
  |     |     |     |-- [Row] (m)
  |     |     |
  |     |     |-- [End_Cn_Section]
  |     |
  |     |-- [End_Cn_Model_Family]
  |
  |-- [End]


* Available Selections

  [Redistribution]
        Full_Public_No_Fee
        Manufacturer_No_Fee
        Do_Not_Distribute
        Specific

  [Begin_Cn_Model_List]
        Mated                    (Mating Column Selection)
        UnMated_Side_A           (Mating Column Selection)
        UnMated_Side_B           (Mating Column Selection)

  [Begin_Cn_Model]
        SLM                      (ModelType field)
        MLM                      (ModelType field)
        Cn_Section               (First Column)
        Cn_Stub                  (First Column)

  [Cn_Columns_of_Pins]
        .. to ..                 Selection (.. are numbers)
        VARIABLE                 Selection

  [Begin_Cn_Auto_Map]
        i
        LASTCOL


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

  Entries new at Version 2.1 and Version 3.2 releases are noted.

.pkg FILE                           (2.1)
---------
  |-- File Data Section             (2.1)             
  |   -----------------
  |     |-- [IBIS Ver]
  |     |-- [Comment Char] (ml)
  |     |-- [File Name]
  |     |-- [File Rev]                  
  |     |-- [Date]
  |     |-- [Source]
  |     |-- [Notes]
  |     |-- [Disclaimer]
  |     |-- [Copyright]
  |
  |-- [Define Package Model] (m)    (2.1)
  |   ----------------------
  |     |-- [Manufacturer]
  |     |-- [OEM]
  |     |-- [Description]
  |     |-- [Number Of Sections]
  |     |-- [Number Of Pins]
  |     |-- [Pin Numbers]                  
  |     |                           (3.2)  Len (m), L (m), C (m), R (m),
  |     |                           (3.2)  Fork (m), Endfork (m)
  |     |-- [Model Data]
  |     |   ------------
  |     |     |-- [Resistance Matrix]      Banded_matrix, Sparse_matrix,
  |     |     |                            Full_matrix
  |     |     |   -------------------     
  |     |     |     |-- [Bandwidth]
  |     |     |     |-- [Row] (m)
  |     |     |-- [Inductance Matrix]      Banded_matrix, Sparse_matrix,
  |     |     |                            Full_matrix
  |     |     |   -------------------     
  |     |     |     |-- [Bandwidth]
  |     |     |     |-- [Row] (m)
  |     |     |-- [Capacitance Matrix]     Banded_matrix, Sparse_matrix,
  |     |     |                            Full_matrix
  |     |     |   --------------------    
  |     |     |     |-- [Bandwidth]
  |     |     |     |-- [Row] (m)
  |     |     |-- [End Model Data]
  |     |-- [End Package Model]
  |
  |-- [End]


.ebd FILE                           (3.2)         
---------
  |-- File Data Section             (3.2)
  |   -----------------
  |     |-- [IBIS Ver]
  |     |-- [Comment Char] (ml)               
  |     |-- [File Name]
  |     |-- [File Rev]
  |     |-- [Date]
  |     |-- [Source]
  |     |-- [Notes]                       
  |     |-- [Disclaimer]
  |     |-- [Copyright]
  |
  |-- [Begin Board Description]     (3.2)
  |   ----------------------
  |     |-- [Manufacturer]
  |     |-- [Number of Pins]
  |     |-- [Pin List]                      signal_name
  |     |-- [Path Description] (m)          Len (m), L (m), C (m), R (m),
  |     |                                   Fork (m), Endfork (m), Node (m),
  |     |                                   Pin (m)
  |     |-- [Reference Designator Map]
  |     |-- [End Board Description]
  |
  |-- [End]