Subject: Re: [IBIS] Comments on BIRD 75.5, part I [LONG]
From: Ross, Bob (bob_ross@mentorg.com)
Date: Fri Oct 18 2002 - 19:12:58 PDT
Michael:
Thank you for your comments. I am accepting some of your suggestions
and some privately from Arpad Muranyi and will issue BIRD75.6 shortly.
I am responding briefly below to your other questions and comments.
In some cases, you have a valid concern or reason for change, but
I am just stating briefly the reason with minimal argument for the
selected choice in BIRD75.6
Best Regards,
Bob Ross
Mentor Graphics
"Mirmak, Michael" wrote:
>
> All,
>
> I have reviewed BIRD 75.5 and would like to add my comments to the
> discussion. Please accept my apologies if some of these issues have been
> raised previously.
>
> PARSER ISSUES:
>
> 1) If 75.5 becomes part of the specification, will future IBIS parsers check
> the syntax of the referenced external code? The document takes great pains
> to allow only Verilog-AMS, VHDL-AMS and (Berkeley) SPICE, with "other
> standards or proprietary formats" being excluded completely. However, if
> the new parser does not actually check the [External Model] or [E...
> Circuit] code, models could be created which violate this exclusion but
> which some vendor tools might still be able to use.
>
> For example, suppose I create a BIRD 75.5-compliant IBIS file which
> references an external model. This external model contains (Berkeley) SPICE
> terms but also contains keywords unique to my own proprietary engine, which
> we will call "MichaelSPICE." Unless the post-BIRD 75.5 IBIS parser is
> capable of checking VHDL-AMS, Verilog-AMS and (Berkeley) SPICE for syntax
> issues and the use of illegal keywords, my "MichaelSPICE"-based model could
> be publicly distributed and there would be no tool-neutral method to prove
> that it does not meet the intent of BIRD 75.5.
>
> In other words, if the rule states that only the three named languages are
> supported, then there must be some means of enforcing this rule. The
> standard parser is the only means by which the Open Forum is able to do this
> across multiple tools.
Briefly, the IBIS Open Forum must consider only public domain or standarized
versions of languages. It will be a parser implementation decision regarding
how to "enforce" the rule. One way for Spice is simply to ask all
model suppliers to get Berkeley SPICE and parse any SPICE code.
In reality, EDA vendors use private versions, and semiconductor vendors
supply SPICE models in one or more private versions. One of the major
purposes of having SPICE is to support on die passive interconnect
extensions for special case analysis. This usually can be done with
the lowest level Berkeley SPICE and supported by all tools. 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.)
>
> ANALYSIS PATH COMMENTS:
Thank you for the comments on the ANALYSIS writeups. This section is to
give justification only. It evolves over time, but is not part of the
official part to be included in the Specification. So I normally do not
make editorial corrections or clarifications in this continually evolving
section.
>
> 1) The document, in several places, discusses what the IBIS specification
> should and should not include. For example, in the Analysis Path section,
> the following text appears:
>
> "The official IBIS list [sic] should not include vendor-specific
> implementations, extensions, or deviations even if they are widely used.
> Vendors can deal [with] this issue by non-compliant IBIS extensions or
> interpretations."
>
> This seems contradictory and somewhat dangerous. The purpose of writing
> specifications is to define what is allowed and considered compliant. The
> document should have no recommendations for "non-compliant" standards. This
> is outside the charter of the specification and could undercut the purpose
> of IBIS as a universal buffer modeling standard.
>
> 2) The phrase "private de facto formats" appears when describing what
> Multi-Lingual IBIS Modeling excludes. This phrase is more clearly expressed
> as "other standards or proprietary formats."
Yes, you have stated this better.
>
> USAGE ISSUES:
>
> 1) No support path is mentioned here for the ICM (IBIS Interconnect
> Modeling) standard, which is also nearing approval. If my understanding of
> the [External Circuit] keyword is correct, expanding the "Language"
> subparameter to cover ICM in addition to SPICE, VHDL-AMS and Verilog-AMS
> would be sufficient to correct this.
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.
However, it is possible to mimic a package specification through
the [External Circuit] keyword and use 0.0 values in place of the package
model. This is NOT the intended application, but it will allow doing
some electrical simulation with complex package structures without
the Interconnect Specification. While the simulations might be correct,
the tool might not interpret the test point locations correctly for
some other automated analysis. So beware, if this work-around is
tried.
>
> 2) Under the [External Model] keyword description, the following phrase
> appears: "If used, the keyword [External Model] keyword must appear only
> once for each [Model] keyword." This limits the model author to either
> (Berkeley) SPICE OR VHDL-AMS OR Verilog-AMS. However, for maximum tool
> compatibility, model authors may wish to include more than one set of
> [External Model] or [E... Circuit] data, to allow use of more than one
> modeling standard. Can the [External Model] and [E... Circuit] definitions
> be expanded to allow this?
No, the way around this is really through several models and the
[Model Selector] keyword to support several model language options.
It is documented and intended that no more than on [External Model] keyword
exists for each [Model].
>
> 3) The [External Model] section describes how differential buffers might be
> implemented using the [Diff Pin] keyword and "individual, single-ended
> buffers." In my experience, using [Diff Pin] along with single-ended
> buffers can lead to undesirable results, at least for receivers. Using
> [Diff Pin] implies a "vdiff," or a minimum differential voltage between the
> pins, which is used to determine if the buffers have switched. I know of no
> buffers which are truly single-ended and yet switch based on the voltage
> relationship to a non-ground or non-Vcc signal pin. The reference to [Diff
> Pin] should be removed from this section.
I may not understand fully this concern. However, existing IBIS supports
single-ended buffers and the [Diff Pin] keyword as an APPROXIMATION to
differential buffer operation. IBIS does not support the true differential
buffer. The individual buffer implimentation is added for existing
IBIS compatibility with existing IBIS models or their representation
using the [External Model] keyword with single-ended buffer models.
However, the [External Model] keyword is the only available method to support
TRUE differential buffer circuit descriptions where the positive and negative
pins do interact, as you describe.
>
> "SPECSMANSHIP":
>
> 1) Under both the [External Circuit] and [External Model] keyword
> definitions, the document describes parameter passing options. In these
> sections, the specific language is that "[p]arameter passing is not
> supported in (Berkeley) SPICE and is therefore not part of the standardized
> support in this document. However, several vendor-specific versions of
> SPICE pass parameters using '.param' statements in the file."
>
> First, the construction of the first sentence implies that parameter passing
> under *-AMS is also prohibited under the BIRD 75.5 extensions! The sentence
> should read, "Parameter passing is not supported in (Berkeley) SPICE;
> therefore, parameter passing with the 'Language SPICE' subparameter is not
> supported."
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.
>
> Second, this passage creates a dangerous loophole which could allow
> vendor-specific (and therefore non-compliant) external models to be used
> with otherwise legal IBIS syntax (see "Parser Issues" above). If only
> (Berkeley) SPICE is permitted under the BIRD, then use of the "Language
> SPICE" combination should explicitly disallow the use of passed parameters.
> Otherwise, this construction will violate the intent of the document as
> expressed in the spec, particularly in the "Analysis Path" section:
> "...IBIS... should not include vendor-specific implementations, extensions,
> or deviations even if they are widely used."
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.
>
> 2) The use of the "corner_name" subparameter and the limitation to only
> three corners are needlessly restrictive. One of the major benefits of
> using modeling languages like *-AMS is the ability to cover combinations of
> conditions not addressed by the standard "typ," "min," and "max" definitions
> (this is becoming a major problem in the system design world). There is no
> obvious reason why the three-corner-only approach should be preserved when
> using *-AMS or even SPICE model formats.
The choice to limit corner_name to the three existing IBIS choices is to
privide direct IBIS compatibility. If more corners are need, then a large
list of corner names are needed for model interchangeability (e.g.,
slow-typ, slow-slow, fast-weak, ....) The workaround is to document
some other corner cases in other models and use [Model Selector]
to select these cases. The documentation given with the IBIS file
would capture this information. However the user would still have to
manually set up each model/corner case for analysis since the models
and corners are not standardized.
>
> A preferable and easily-implemented solution would be to allow the use of a
> variable, such as "case," "condition_set" or something similar in place of
> "corner_name" and allow more than three lines under the subparameter (of
> course requiring at least one be present). Alternately, a variation of the
> [Model Selector] syntax could be used which accomplishes the same purpose.
> This permits maximum flexibility to the model author and the user.
EDA tools require standardize names for model interchangeability. Vendor
A may choose corners a, b, c, and Vendor B may choose corners 1, 2, 3 to
coincidentally mean the same thing. The EDA tool has no way of knowing
what is common or what these corners really mean. So the [Model Selector]
alternative does the same thing as a variable name. In all cases the
user has to control what to use.
>
> DOCUMENT ORGANIZATION AND CLARITY:
>
> 1) The words "node," "port," and "terminal" are used repeatedly and
> interchangably throughout the document. Unfortunately, only one of these
> terms is even partially defined there. All three should be defined,
> preferably in one of the early sections of the BIRD.
BIRD75.6 will have some additional text in this area.
>
> 2) The "EXTERNAL LANGUAGES" section includes a very long sentence to
> describe the state of the Verilog-AMS language and to explain who or what
> "Accelera" is. The text reads:
>
> "'Verilog-AMS' means Analog and Mixed Signal Extensions to Verilog-HDL as
> documented in the Verilog-AMS Language Reference, Version 2.0. This
> document is still being developed by Accellera (formerly Open Verilog
> International), an independent organization and author of the Verilog
> Hardware Description Language IEEE 1364-2001. In the future..." etc.
>
> This is very confusing and leads the reader to conclude that the spec is not
> finished but still has an IEEE standard number! References to the status of
> Verilog-AMS should be made in sentences completely separate from those
> describing the background of plain Verilog or Accelera.
This section is being revised in BIRD75.6 to clarify this. It will
position Verilog-AMS as a superset of Verilog and Verilog-A. Only
Verilog is an IEEE standard. The "future" reference is deleted.
>
> To be continued...
>
> - Michael Mirmak
> Intel Corp.
> michael.mirmak@intel.com
-----------------------------------------------------------------
|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 : Fri Oct 18 2002 - 19:20:47 PDT