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:11:49 PST

Next message: Todd Westerhoff: "RE: [IBIS-Users] Questions Regarding Bird 75.8"
Previous message: Timothy Coyle: "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 ]

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

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

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

Regards,
Tim

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

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

-----Original Message-----
From: Timothy Coyle [mailto: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

Next message: Todd Westerhoff: "RE: [IBIS-Users] Questions Regarding Bird 75.8"
Previous message: Timothy Coyle: "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 - 11:19:31 PST