RE: [IBIS-Users] Questions Regarding Bird 75.8

Subject: RE: [IBIS-Users] Questions Regarding Bird 75.8
From: Timothy Coyle (Timothy.Coyle@nsc.com)
Date: Tue Jan 07 2003 - 13:01:20 PST

Next message: Tom Dagostino: "RE: [IBIS-Users] Questions Regarding Bird 75.8"
Previous message: Todd Westerhoff: "RE: [IBIS-Users] Questions Regarding Bird 75.8"
Maybe in reply to: Timothy Coyle: "[IBIS-Users] Questions Regarding Bird 75.8"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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

Regards,
Tim

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

Tim,

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

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

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

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

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

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

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

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

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

-----Original Message-----
From: Timothy Coyle [mailto:Timothy.Coyle@nsc.com]
Sent: Tuesday, January 07, 2003 8:30 AM
To: ibis-users@eda.org
Subject: [IBIS-Users] Questions Regarding Bird 75.8

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

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

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

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

Regards,
Tim

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

Next message: Tom Dagostino: "RE: [IBIS-Users] Questions Regarding Bird 75.8"
Previous message: Todd Westerhoff: "RE: [IBIS-Users] Questions Regarding Bird 75.8"
Maybe in reply to: Timothy Coyle: "[IBIS-Users] Questions Regarding Bird 75.8"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

This archive was generated by hypermail 2b28 : Tue Jan 07 2003 - 13:12:00 PST