Subject: IBIS 3.0 and legal questions

From: Stephen Peters <[email-masked]>
Date: Fri, 08 Aug 1997 13:54:24 -0700

Hello All:

     I concur with Jon, at least as far as vendors publishing
model which are labled IBIS 3.0.  Specifically, the IBIS forum should
strongly discourage model vendors from publishing .ibs files with
"3.0" as the parameter to the [IBIS Ver] keyword, at least until the
spec has gone thru the ballot process (and ideally until the parser is 
developed).  My fear is the same as Jon's -- a model with 3.0 syntax will
almost certainly NOT be a correct IBIS 3.0 model.  If someone wants to publish
a model with 3.0 features, then I would suggest that they either leave 
the [IBIS Ver] blank, or put in something like PRELIMINARY or EXPERIMENTAL,
or give the file something other than an .ibs extension.

Comments, or course, are welcome, and (if you absolutly, positivly must)
you can correct my spelling :)

                    Regards,
                    Stephen Peters
                    Intel Corp.

>on  Fri, 08 Aug 1997 10:41:24 Jon Powell wrote:

Hello All,

I sent this note out last week but evidently it didn't get out over the
reflector. I hoped to at least spark some controversy.

This is my feelings on IBIS 3.0 and releasing models in this format.

The copyright for the name IBIS is owned by EIA. Until 3.0 is approved
by that body, IBIS 3.0 does not exist. If anyone publishes models
claiming to be IBIS 3.0 then they are in violation of that copyright and
EIA will probably be forced to take action. 

Besides the legal implications, anyone publishing IBIS 3.0 models before
the official approval is almost certainly to be publishing models which
will NOT be correct. We had to change things to do 2.1 and we will
probably have to change things for 3.0. I will certainly not be putting
any "IBIS OFFICIAL 3.0" models into any of the IBIS data areas until
this specification is approved. I feel very strongly about this. I do
not want what happened to EDIF to happen to IBIS. If you recal, EDIF
(the earlier versions) was almost unusable because everyone had their
own dialect of the "standard" and it was virtually impossible to support
every dialect. At the same time, everyone claim to support EDIF. 

Perhaps we need some PRELIMINARY or EXPERIMENTAL designation for these
new models but we should NOT call them IBIS 3.0.

comments, of course, are solicited.
(but don't correct my spelling).

Jon Powell
Senior Scientist, Viewlogic Consulting Services.
IBIS Librarian

---

From: [email-masked] (Syed Huq)
Date: Fri, 8 Aug 97 14:20:58 PDT

To all:

A lot of hard work has gone into creating the v3.0 spec. A lot
of 'bad/corrupt' models can easily find their way into the
public domain if not parsed properly thru the v3.0 parser(..which
is coming soon..).

I personally think that the IBIS community should not encourage
IBISv3.0 model distribution unless the v3.0 parser is out/debugged
and approved.

If you must create a v3.0 model, do it and contain it between you
and your EDA vendor. Do not pass this to your customer or to
the public yet....An ASCII file without properly parsed will do
more harm than good.

Regards,
Syed
Vice-Chair ANSI/EIA-656
National Semiconductor Corp.

---

From: "Leonard, Mark" <[email-masked]>
Date: Fri, 8 Aug 1997 17:09:26 -0500

I've read through the responses from tool and model suppliers, and the 
perspective from a model user is very different.  We're actively 
pursuing simulation information for devices, memory modules, processor 
modules, etc. that can only be accurately represented with v3.0 
syntax.  Our choices have been limited to the following: get the 
information directly in Quad Design format, exert pressure and get it 
in a painful combination of Spice and CAD (Allegro) formats, or don't 
get it at all.

It's quite interesting to note that Quad XTK models are becoming more 
readily available for most of the devices we care about.  It's also 
interesting to see some of our competitors being forced to switch 
simulation tools for this very reason.  I'm seeing buffer technologies 
continuing to advance, simulation engines advancing along with them, 
and the IBIS spec continuing to fall behind.  V3.0 catches up to where 
we are today, but it will be behind again in very short order.

The v3.0 spec has allowed us to start pushing the "don't get it at 
all" cases.  Accordingly we're starting to see v3.0 models.  I 
certainly wouldn't trust v3.0 models from just any vendor, but I some 
level of confidence in most of these guys.  From a user perspective I 
generally don't trust v3.0 models any more than I trust v2.1 models 
(assume they're of limited value until proven otherwise).  We still 
see a surprising number of v2.1 models with various problems (syntax, 
questionable data, etc.).

The lack of a v3.0 parser and tool-specific translators is forcing us 
to write our own.  We're left with no choice.

Mark Leonard
Manager, Signal Integrity & Package Analysis
Compaq Computer Corporation

-----Original Message-----
From:	c=US;a= ;p=COMPAQ;dda:ZID=<huq(a)rockie.nsc.com>;
Sent:	Friday, August 08, 1997 4:21 PM
To:	Leonard, Mark; c=US;a= ;p=COMPAQ;dda:ZID=<ibis(a)vhdl.org>;
Subject:	Re: IBIS 3.0 and legal questions

To all:

Regards,
Syed
Vice-Chair ANSI/EIA-656

---

From: Scott McMorrow <[email-masked]>
Date: Fri, 8 Aug 1997 15:25:27 -0700 (PDT)

To all:

I believe I have heard some of the silliest arguments
for not distributing IBIS 3.0 models today.

Anyone who has actually dealt with IBIS models from
semiconductor vendors (including Intel and National, among
others) knows that "parser problems" are the least of
our worries. I have personally used hundreds of models, most
of which passed the "golden parser", only to discover 
fundamental problems with the underlying data.  Often I/V
curves and waveform tables are incorrect.  Often the incorrect
units are used.  Often clamp curves are extracted improperly.

It is wonderful that the IBIS committee has gotten to the point 
of publishing the version 3.0. specification.  If we wait for
a 3.0 golden parser ( which, by the way, is an aid to checking
compliance with the specification, not the specification itself),
we in the design community will be waiting for another year.  
The argument that the specification will change in the future does
not hold water.  All specifications change over time. It is 
through "real life" experience with using the results of a 
specification that is the impetus to change.

Currently, the design community requires the ability to model
multistage drivers, complex series elements, and modules.  There
is no way in IBIS 2.1 to perform these modeling tasks.  There is
currently no common public way to distribute this silicon and
packaging information amongst the design community.  We have a crisis
for designs trying to achieve 100Mhz and above bus speeds with
complex products in increasingly shortening design times.  Yet
members of the IBIS committee (and specifically representatives of
the companies that need to provide this sort of data to customers)
are afraid to release information because the specification (which
they approved) could somehow be imperfect.

Guess what?  All specifications are imperfect!  However, an imperfect
3.0 specification is far superior to a perfect IBIS 2.1 specification.
What I need as a designer is data from which I can model and 
analyze my boards and chips.  I choose to receive this data in the
IBIS 3.0 format.  I choose to receive it as soon as possible.  I
believe that most designers who actually design boards for a living
would rather have the best design information that they can have 
right now.

Semiconductor vendors, please get off the stick and provide IBIS
3.0 compliant models today.  It would be irresponsible and 
inexcusable ( that is, unless you want to impede progress) to do 
anything otherwise.  If you wish, use the IBIS Disclaimer field
to qualify the preliminary status of your models.  The field
is already used to disclaim the suitability of the models for
any purpose anyway.

I hope that other boards designers and consumers of IBIS models
will also speak up.  I look forward to your comments.

[email-masked]