Subject: Re: [IBIS] Comments on BIRD 75.5, part I [LONG]
From: Ross, Bob (bob_ross@mentorg.com)
Date: Thu Oct 24 2002 - 17:46:40 PDT
Arpad:
Thank you again for your thoughtful comments. My responses
below now support one of your major points, and proposes a
resolution for another. We may cover some more details in
direct discussion.
Bob
Mentor Graphics
"Muranyi, Arpad" wrote:
>
> 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?
>
BR - You have made your point, and I agree with you from a Specification
purity point of view. Therefore, I plan to remove all references
which even imply a back door to vendor-specific forms of SPICE.
There is still plenty that you can do with generic Berkeley SPICE
with respect to passive interconnect structures and even active
controlled elements and public models to justify keeping SPICE.
> "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.
BR - This could be a case where each of us has assumed what we wanted to
hear. An interconnect structure for on-die interconnect was a necessary
component of BIRD75, and one was proposed early on as part of BIRD75.
Therefore I never assumed that the Interconnect Specification would be
needed or used within BIRD75. SPICE interconnects were needed and are
supported along with necessary connectivity rules for the VHDL-AMS and
Verilog-AMS languages.
So I never assumed that the Inteconnect Specification would be
used for on-die interconnects for the first release. Nor was it
explicitly stated that it was to be used for on-die structures.
Thus I gave my direct answer above. It is not yet stable, so
I think it should be considered as for a future "Language"
extension when ready, not for the first version. A number of
issues need to be sorted out because we need to determine
exactly what information is of interest and how to get to
it under several conditions and levels of hierarchy.
>
> "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?
Multiple [Exteral Model]s can exist (for a variety of conditions or
languages). This could be done (with care) using [Model Selector], or
through different [Component] definitions. Because several EDA tools
already exist that co-simulate with multiple languages, automatic
[External Model] selection or variation cannot be assumed. So that
is why the single [External Model] for each [Model] exists. I do not
see multiple models as a big issue in the near future, and for specific
configuration cases, the above work-arounds are adequate and practical.
>
> "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.
BR - I will take out the back door references and even make the statement
that Parameters are not supported in all Languages (leaving the door open
for some future "Language" extensions that do not support parameters.)
>
> "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!!!
>
BR - I agree, no promotion.
-----------------------------------------------------------------
|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 : Thu Oct 24 2002 - 17:59:19 PDT