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

From: Bob Ward <[email-masked]>
Date: Thu, 16 Dec 1993 08:48:38 -0600

All -

I actually agree that the question of mutuals is othogonal to the pin mapping
that this BIRD deals with.  It occurred to me at the time of writing so I
mentioned it.  I have no problem at all with saving it for another BIRD, and
had thought about adding it to one I am trying to work out to generalize the 
mapping for more complex cases such as I presented earlier.  Still the
suggested EGG ( I like that ! ) has a lot of merit.  I also like the idea of 
the separate [PackageModel] keyword.  It occurs to me that some kind of file
include mechanism, such as the (in)famous #include in C or ~r in many e-mail
programs which takes a path name as argument and merges the contents of it in
line in the text would be useful in this context.  It should fit into the
established keyword syntax, however, such as maybe [Include], [Library], 
[Merge], or [Read] or some such variation.  Path names can easily exceed the 
80 character limit, though, and I do support that limit as a matter of 
practical convenience, even though not dogmatically.  Thus we may have some 
extra baggage here such as a [path] keyword, use of the path environment
variable on UNIX(tm) and DOS systems, or even add an environment variable 
such as ibispath.

I am still thinking about how to best represent mutuals.  Much can be said
for the matrix approach, as well as the text based approach in the EGG, and I
have yet to convince myself of a compelling reason to come down on one side 
or the other.  One caveat though: beware of arbitrarily deciding that some 
mutuals can be eliminated due to their small magnitude.  Jacob White of the 
Research Laboratory of Electronics at MIT has some interesting examples of
packaging where, due to the nature of the internal circuitry, a number of 
"far away", and thus small magnitude, mutuals "ganged up" on another signal 
pin and ruined the waveform there during certain transitions.  So there needs
to be a basis for discard of mutuals, probably based on knowledge of some
constraints on simultaneous switching patterns.

Anyway this sounds like just the level of discussion I had wanted to start
about mutuals, etc.  Sounds like a number of good ideas coming forth, and
that is the stuff that will move ibis forward.

Thanks,

=============================================================================

     __                          /             
    /  \                  /     /                     Bob Ward
   /__ /        /        /  /  /            /   MSG:  SQU       
  /    \  _    /_       /  /  /  _   __  _ /   INET:  [email-masked]
 (____ / (_)_ /__)     (__(__/  (_(_/ (_(_/           713+274-4146 Voice
                                                      713+274-3911 Fax

=============================================================================

---

From: [email-masked] (Randy Harr)
Date: Thu, 16 Dec 93 09:52:19 PST

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