Subject: RE: [IBIS] Comments on BIRD 75.5, part I [LONG]
From: Muranyi, Arpad (arpad.muranyi@intel.com)
Date: Tue Oct 22 2002 - 08:24:25 PDT
Bob,
I feel I need to put in a couple of responses. To make them easier
to find, I removed much of the original messages and retained only
those sections to which I am responding.
Thanks,
Arpad
===================================================================
-----Original Message-----
From: Ross, Bob [mailto:bob_ross@mentorg.com]
Sent: Friday, October 18, 2002 7:13 PM
To: Mirmak, Michael
Cc: 'ibis@eda.org'
Subject: Re: [IBIS] Comments on BIRD 75.5, part I [LONG]
"Non compliant extensions might be provided for more detailed SPICE buffer
models and circuits using private SPICE syntax to the extent that
is already done. These models are not portable. However, such support is
a business decision that is out of the control of the IBIS Open Forum.
(And the bottom line is that model development/usage and support
is dictated by real business/technical needs.)"
AM: This means that a company (or groups inside companies) can - for their
selfish business reasons - undermine one of the main achievements of the IBIS
spec, that is portability or vendor independence. In fact, the IBIS spec
will point them the way and show them how to do it. Is this what you want
to achieve?
"BIRD75/77 apply only to the die and ends at the die boundary (where the
package model begins). The Interconnect Specification applies to a
different region: (1) either die boundary to pin boundary for packages, or
(2) pin boundary to pin boundary for connectors.
So there is no interaction or overlap with [External Circuit] and
the Interconnect Specification."
AM: Quote from the General introduction of the ICM spec: "It was written
to provide means for modeling all electrical interconnect types, including
connectors, cables, packages, and printed circuit boards." True, this
doesn't mention on-die interconnects, but doesn't exclude them either. So
I don't see why the ICM spec couldn't be used for on-die interconnects.
"It is documented and intended that no more than on [External Model] keyword
exists for each [Model]."
AM: Is there a reason for this? Why couldn't multiple [Model]s be allowed?
"This is a very difficult area to document. Officially parameter passing
is not supported using SPICE. However, there was much push for adding
parameter passing because several SPICE languages have a common .param
optional extension. This is one case where a loophole is generated and
and even documented for some business and practical reasons. However
officially compliant IBIS models will NOT permit parameter passing in
SPICE. Some EDA tools and some vendors may choose to support this
non-compliant "extension" for some real problems."
AM: If Berkeley-SPICE doesn't support it and if this spec only supports
Berkeley-SPICE, we shouldn't open the back door and allow (or promote)
other SPICE flavors by allowing something that is not supported by Berkely-
SPICE.
"The statements above apply here. The IBIS committee has no control whether
the EDA tool complies exactly with IBIS or supports vendor specific
extensions (or relaxed interpretations) of rules."
AM: But we shouldn't promote these kinds of models by giving the readers
ideas about how to do it!!!
===========================================================================
-----------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with 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 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 Oct 22 2002 - 08:33:06 PDT