Re: Yet Another Comment ( Sorry, I can't get another "C" in here )

I agree with the [PackageModel] concept and will await the BIRD eagerly.

Concerning the "include" mechanism, there is much previous experience which
can be learned from here. Newer standards (VHDL, EDIF, etc.) have
learned that referencing an outside file invaribly leads to trouble. The
biggest portion of that trouble is a "path" specification, if included.
When "path"s are allowed, they invaribly represent a fixed, hard path on
the source machine and are never represented the same on the receiving
machine. It forces someone to go around looking for files, reorganizing
directories, changing the IBIS files to fix the path, etc.

VHDL solved this by allowing a "library" designator -- single word. It
is not defined how a "file name" and "library" map to a given OS file
system.

In addition, many times one wants to transmit (in an EDI sense; possibly
via email, etc.) the IBIS file to someone else. Transmissions of this
sort usually do not have good conventions for dealing with multiple file
designations. On top of that, when there are multiple files involved, it
requires the concientious sender to peruse the IBIS file to find any and all
file references, find the files, and then send them.

DIE format and SGML DTD's (instance models of ISO 8879 style documents) allow
for either a file reference or direct inclusion of the text. The direct
inclusion method complicates parsing a little but guarantees inclusion when
the intent is transmittal of the IBIS model.

We have precedence in the format now where some boxed ([]) keywords are
followed immediately by processable information; some followed by (implicit)
comments on the rest of the line with the real information starting on the
next line. Look carefully at the IBIS 1.1 spec for this.

Based on this, I would suggest the following prototypes:

1) Combined:

[PackageModel] <name> <library name> <file name>
<< included file text if library name and file name not present >>
[***]

2) Split

[PackageModelFile] <name> <library> <file name>

or

[PackageModelInclude] <name>
<< included file text >>
[***]

In both cases above, [***] represents the next allowable IBIS keyword.
Note that to make this work (simply), one needs to be careful about allowing
IBIS Keywords in the included file / text of the Package Model.

We might want to consider the [Model] to be "includable" in this same light.
Many times, one might want to transmit a single part to a user which is created
from a library of many parts sharing the same "Model"s. From first glance
this could be an "upward compatible" change.

To do this though, we need to refine the 1.1 description. Currently, it is
not explicitely stated that a [Voltage range], [Pulldown], [Pullup],
[GND_clamp], [POWER_clamp], and [Ramp] are always in reference to the
preceding [Model] definition (that is, they are sub-keywords of the [Model]).
That is, we need to create a flow chart (Syntax chart or BNF) for the boxed
keyword sections allowable.

I propose, at minimum, the following be described more formally and included
in the specification (in lieu of a formal BNF or syntax chart):

[IBIS Ver]
[Comment char]?

[File name]
[File Rev]
[Date]?
[Source]?
[Notes]?
[Disclaimer]?

[Component]+
 [Manufacturer]
 [Package]
 [Pin]
[Model]+
 [Voltage range]
 [Pulldown]?*
 [Pullup]?*
 [GND_clamp]?*
 [POWER_clamp]?*
 [Ramp]?*

Keywords at the same level of indentation that have no intervening blank
lines are in the same group. Keywords in a group can occur in any order.
(allowable, in general? If a modification instead of clarification of the
current spec to make this true, this is an upward compatible but not backward
compatible change. Is that ok?)

Groups of keywords at the same level must occur in the order the groups
are specified.

Keywords followed with a "+" in this chart can occur one or more
times. Keywords followed with a '?' can occur zero or one time. Keywords
followed by a '?*' can occur zero or one times but have extra requirements on
when they can or cannot occur.

All keywords one level down from a previous indentation before the
indentation goes back up a level are part of a group and sub to the keyword
in the previous level of indentation. If a keyword that heads
a subgroup can be repeated, then the subgroup members can be repeated
after another occurrence of the subgroup header keyword.

Optimally, we should develop a formal BNF (and information model) for IBIS
as this will clarify many items and lead to clearer thinking and understanding
of the syntax. This is especially true for the 80 column discussion going on.
When is the <carriage return> (<newline>, whatever) a terminator/separator for
a keyword or other item?

LMC will accept a task to develop and maintain a BNF description (or syntax
chart), at minimum, if this is desired. (There is precendence. VHDL 1993
had a formal requirements generation committee (like BIRD's), which fed a
formal language design/change committee (BNF, syntax, semantics, etc.), which
fed a formal Language Reference Manual change committee.)

randy
Received on Thu Dec 16 10:02:07 1993