Subject: [IBIS] Comments on BIRD 75.5, part I [LONG]
From: Mirmak, Michael (michael.mirmak@intel.com)
Date: Fri Oct 11 2002 - 09:42:53 PDT
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.
ANALYSIS PATH COMMENTS:
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."
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.
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?
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.
"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."
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."
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.
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.
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.
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.
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 11 2002 - 09:59:34 PDT