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 - 11:02:43 PST


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

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

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

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

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

Regards,
Tim

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

Timothy,

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

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

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

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

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

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

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

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

Chris

-----Original Message-----
From: Timothy Coyle [mailto:Timothy.Coyle@nsc.com]
Sent: Tuesday, January 07, 2003 8:30 AM
To: ibis-users@server.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



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