Subject: IBIS Connector Specification Editorial Review

From: Bob Ross <[email-masked]>
Date: Mon, 10 Jan 2000 14:24:06 -0800

To IBIS Committee:

I appreciate the amount of work and consideration that was needed
to produce the Version 0.92 Connector Specification.  Overall, the
document contains a lot of good material and is very comprehensive.

This review is mostly editorial and deals with syntax and conventions.
The emphasis of most comments is to align the Connector Specification
more closely with IBIS Version 3.2, or else to understand why we should
deviate.  In any case, we can discuss these and other comments at
the next meeting and on the reflector.

While IBIS Version 3.2 is not perfect and some deviation is needed,
I believe unnecessary deviation should be avoided for several reasons:

  Minimize confusion between documents over syntax
  Simplify the document and parser development/testing
  Speed up the formal adoption
  Leverage on the latest publicly reviewed document

I will probably have more comments as a result of further reading
and technical review.

Bob Ross
Mentor Graphics

GENERAL:

1. I would prefer keywords with 3 or less individual words since
both the IBIS and Connector keywords allow both the underscore "_"
and space characters as separators.  This keeps the variations that
need to be stored to 8 or less.  One suggestion is to eliminate 
"Cn_" in many of the keywords.

2. The existing IBIS extensions are .ibs, .pkg, and .ebd.  The new
document proposes .ibiscnn.  The practical reason for 3-letter
extensions no longer exists.  However, I still would favor .cnn or
some other 3 letter choice because the file name itself may be
a column entry in some new keyword (such as [Reference Designator Map]
in an EBD).

3. The new format sets the line length limit to 120 characters but 
restricts comment lines to 80 characters.  I would favor keeping the 
80 character limitation throughout, but would also accept 120 
characters throughout.  Having two limits provides unnecessary
complication in the document and in the parser.

GENERAL SYNTAX RULES AND GUIDELINES SECTION:

1. Item 2) adds reserved word PWRGND.  This is unnecessary since
POWER can be used to include GND.  Also RET is not referenced 
anywhere else in the document.  I do not think it is necessary.

2. Item 3) in the IBIS Version 3.2 setting file name case and
size limits is omitted.  I would add that paragraph.  Note, the
information is moved to the [File Name] keyword.  More comments
on this are below.

3. Item 3) in the Connector Specification should be replaced by 
the text of Item 4) in IBIS Version 3.2 (changed from 80 to 120
characters, if that is the consensus).

4. Item 5) in the Connector Specification should be replaced
by Item 6) in IBIS Version 3.2 to clarify the keyword syntax.

5. Item 8) in the Connector Specification should be replaced by
the updated Item 10) in IBIS Version 3.2 regarding tab character
usage.  The reference to 80 characters could be replaced by
120 characters if 120 is chosen as the line length limit.

6. I recommend deleting Item 11) regarding location of files.
This is out of date.  This information might be better located
in a general introduction section.

7. Item 13) regarding number of decimal points in a number should
be eliminated.  There are probably exceptions on each end.

As an alternative, a general recommendation similar to IBIS Version 3.2
regarding I-V and V-T data in Item 9) could be added recommending
up to 5 decimal digit accuracy where necessary.

8. Item 14) in IBIS Version 3.2 regarding defining ASCII characters
should be added.

FILE HEADER INFORMATION:

1. [IBIS_Cn_Model_Ver]:  I would change to [Conn Ver] to 
(parallel to [IBIS Ver]) to distinuish a Connector file.  I would
start with [Conn Ver] 1.0.  I would use the same text as the used
for [IBIS Ver] except substituting CONN for IBIS.

2. [Comment Char]: I would use the latest IBIS Version 3.2 
description since it lists the permitted versus excluded characters.

3. I do not see any reason for creating new rules for the common
IBIS Verison 3.2 keywords [File Name], [File Rev], [Date], [Source],
[Notes], [Disclaimer] and [Copyright].  While IBIS rules may not
be perfect, they are, in practice, quite adequate.  The discriptions
should be the same as in IBIS Version 3.2 (except with modifications
appropriate for the Connector File).  Some new number of line limits
may be practical, but would require new checks in an area where we
really do not have practical problems.  The [Copyright] limit of
4 lines is not realistic.  Many files have full Copyright statements
with many paragraphs.

4. The [File Name] lengths should be consistent with IBIS Version 3.2.
(either 20.3 or 20.7 if .ibiscnn is used).  The reason is that in
the future the file name may be one entry in the column of another
keyword - e.g., [Reference Designator Map] in an EBD.

5. The [File Rev] rules can be adapted for connector recommending
0.x and 1.x as given.

6. The [Manufacturer] keyword should be positioned under the [Begin
Cn Model Family] description keyword, consistent with usage in IBIS
Version 3.2 positioning.

7. I recommend eliminating the [Web Site], [Email] and [Redistribution]
keywords at this time the following reasons:
- Not consistent with IBIS Version 3.2 files - they are NOT a common
  keywords.
- The information can be easily handled within the [Source], [Notes] and 
  [Copyright] keywords
- The removal will simpify the parser and document
- With Company mergers, acquitions, name changes, etc. these keywords
  may contain out of date information.
- The only legal terms should be [Disclaimer] and [Copyright].  Business
  conditions implied by the [Redistribution] keyword are typically
  spelled out in detail in the [Copyright] keyword or do not seem
  appropriate in a data file.  Only the [Copyright] keyword is "required"
  by IBIS to be in "derivative" models; the others are recommended.

CONNECTOR ELECTRICAL SPECIFICATION

In general, I would simply the syntax to remove some of the keywords
to be consistent with IBIS.  I would recommend per the general comment
above to simplify the keyword names.

1. The [Begin ..] [End ..] is an unnecessary complexity for some of
the keywords.  I would use [Begin ..] [End ..] (or some variation)
consistent with the for just the major groupings, not Description
lines.  It is common and well understood for a new keyword to terminate
a list or table.

I would position [Manufacturer], and "[Family Description]" and
[Model List] directly under [Begin Cn Model Family] keyword.

I would position a single keyword [Description] under each [Begin
Cn Model] keyword.

2.  In terms of organization, the keywords grouped under
[Begin Cn Model] should be described next.  Then the keywords outside
of this grouping should be described:  [Begnin Cn Pin Map],
[Begin Cn Phy Map] and [Begin Cn Section]. 

3. [Row] under [Begin_Cn_Phy_Map] should be renamed since the
meaning of [Row] is inconsistent with its usage under the [.. Matrix]
keywords.  This is a reference to a physical row, not a matrix row.

4. In IBIS Version 3.2, [Row] uses the pin names whereas which can be
alpha-numeric characters.  [Row] and other matrix entries are limited
to sequential indices.  This is noted.  Some comment might be added to
emphasize there is a difference. 

5. The "subparameters" in IBIS Version 3.2 for Full_matrix, Sparse_matrix,
Banded_matrix and the new Diagonal_matrix are documented both as
keywords and subparameters in the Connector Specification.

---

From: Al Davis <[email-masked]>
Date: Mon, 10 Jan 2000 21:41:57 -0800

Regarding the header section ....

I agree that the header section should be EXACTLY the same
as the other IBIS files (which should be EXACTLY the same
as each other), but there are some good points here, that
probably should make their way to all IBIS files.

There should be a document describing the header section,
that others should reference, not repeat.

Basic syntax rules should also be consistent, and stated
only once in a document that applys to all IBIS family
files.  (max lengths, case sensitivity, basic form,
optional parameters, how scoping is specified, ...)

In general, I think the committee should not legislate
aesthetics.  The existing IBIS standard goes way too far at
legislating aesthetics.

Now, I take issue with Bob's comment ......
>   by IBIS to be in "derivative" models; the others are recommended.

In this case, I believe that the new fields should be
added.  The old ones Disclaimer and Copyright are not
really necessary because they could be in a general comment.

Actually, one could say that the whole header could just be
a comment.  The only reasons not to do this are 1. to make
sure the info is not omitted, and 2. to assist in
automation in processing libraries.

The new ones [Web Site], [Email] and [Redistribution]
really do serve a purpose, and should be there in a
specific form.  One reason is that some simulator vendors
supply a library of models with the simulator.  This is a
great convenience to the customers, but can be a big
headache to maintain.  With these fields as suggested here,
the process can be more automated.  Without them, it is
necessary to manually process every file. 

Therefore, I recommend that they be added to other IBIS
files, too.

The tree diagram (posted by Bob Ross) should be
incorporated as official.  (Same goes for the other IBIS
files.)

---

From: Kellee Crisafulli <[email-masked]>
Date: Tue, 11 Jan 2000 17:40:30 -0800

Hi all,
  
  I have added the keyword tree table (Thanks
to help from Bob Ross).  The keyword table is located
at the top of the specification.  I have also
nearly completed adding "usage" rules for every keyword 
as requested by Arpad.  I am planning to 
upload the updated V0.93 specification by Wednesday late.

It should be available for review all day
Thursday prior to the Friday meeting.

If possible I would still like to put it up for a vote
at Design Con.  As I recall we cannot make any changes
for two weeks prior to a final vote and it will
still meet that requirement.

best wishes..
Kellee

---------------------------------------------------------
Have a great day....
Kellee Crisafulli 
HyperLynx, a division of Pads Software Inc.
SI,EMC,X-talk and IBIS tools for the Windows platform
E-mail: <mailto:[email-masked]>
web:    <http://www.hyperlynx.com>
---------------------------------------------------------

---

From: "Matthew Flora" <[email-masked]>
Date: Wed, 12 Jan 2000 10:19:28 -0800

Dear Bob,

> "Cn_" in many of the keywords.

This really is just a matter of preference.  The parser actually scans each
keyword candidate and converts all the spaces to underscores before converting
the keyword candidate to uppercase.  The resulting keyword candidate string is
then compared to the list of keywords.  So, there really is only one keyword
lookup for each candidate.  (In other words, only one variation of each
keyword is stored.)

> anywhere else in the document.  I do not think it is necessary.

I would recommend against using POWER to mean both ideal-ground and non-ground
(ideal or otherwise) else this use of the POWER keyword would be a special
case that differs from the usage in IBIS [Component] and EBD pin lists.

> lines.  It is common and well understood for a new keyword to terminate

One of the complaints about the IBIS spec is that it has some inconsistencies.
Using [Begin ..] [End ..] consistently for all keywords seems appropriate.

My two cents,
Matthew Flora

---

From: Kellee Crisafulli <[email-masked]>
Date: Thu, 13 Jan 2000 09:26:22 -0800

To IBIS Committee:

I have made several more changes to the specification:
1) Added a table of contents 
   (copy of the one form IBIS IC specification)
2) Added a General Introduction section
   (copy of the one form IBIS IC specification)
3) Added a Revision history section
4) Added keyword tree diagram section

Also I have responded to Bob's comments below:

(Bob wrote)
>"Cn_" in many of the keywords.
I believe Matt addressed this one, it makes no difference to the
parser, there is only one variant the way it is coded.
So I feel Cn_ keywords should stay.

>a column entry in some new keyword (such as [Reference Designator Map]
.cnn was rejected because so many other tools have already used
this extension for something different or connector formats
they may already have.  As you point out there is no reason to stick
with 3 characters any longer (DOS is dead).
So I feel we should keep the committee's .ibiscnn extension.

>complication in the document and in the parser.
The complication to the parser of two line limits is insignificant.
I feel the complication to creators of connector models will be minor
and the gain is that a standardized display area in CAE tools can be
established at 80 characters.  This allows a reasonable display size
in most windows.  The need to got to 120 characters is for readability
of the large matricies needed for connectors in many cases.
I propose the 120 limit for all lines except comments be upheld
for improved readability of matricies.
I propose that the 80 character limit for comments be upheld for
improved readability of comments when displayed in CAE tools.  Since
we have hard-coded end of line characters maintaining tabing and
alignment without such a limit is very difficult.

>anywhere else in the document.  I do not think it is necessary.
The RET reserved word was specifically requested by several connector
companies to more formally indicated that it is not "GROUND".
This was very important to several of the sub-committe members.
I suggest we keep RET and the PWRGND reserved word to allow
additional flexability as desired by the model builders in describing
how the model is expected to be used.  As this was their desire

by including these keywords.
I did notice an inconsistant use of the reserve word PWR which I have
changed in the specification to POWER.

>characters, if that is the consensus).
I disagree on this one the 120 character limit is needed for
matrices and this is too wide for comments that need to be displayed
within CAE tools.  Therefore I feel the 120/80 limits are
justified.

>by Item 6) in IBIS Version 3.2 to clarify the keyword syntax.
I agree, I made this change and copied item 6 in V3.2 spec.

>120 characters if 120 is chosen as the line length limit.
The existing specification does not accent the potential problem \
with a warning statement as does the new text.
I did change the line so it removes the 120 comment and
just says it may make the line too long causing a syntax error.
That way no matter what we decide for line lengths this paragraph
is correct.

>in a general introduction section.
I agree.  I changed item 11 as follows:

| 11) Important information is contained in the sample files provided
|     with the specification and these should be refered to as a
|     starting point for creating new models.

>be eliminated.  There are probably exceptions on each end.
This was discussed extensively by the sub-group.
It was noted that since these models will mostly be automatically
generated there is no reason not reduced the garbage in the file
by limiting the data size within reason.
I do feel the 5 digit mantissa suggestion and 15 digit limit
are very reasonable.  It was noted that many files had been created
for which the data was only accurate to 3 digits and 12 or more digits
of information was provided.  This not only wastes file space on
all the computers storing data it is also plain wrong.  The number
of digits generally indicates the accuracy of a measurement.  If
12 digits are shown then that should be the accuracy of the data.
Again this is worded as a suggestion only.  The actual limit is reasonable
considering the double precission limits of unix/IEEE numeric processors
which 
are many times smaller than windows numeric processors.

>up to 5 decimal digit accuracy where necessary.
I believe the text that is present does just this.  I don't see any

need to change item 13.

>8. Item 14) in IBIS Version 3.2 regarding defining ASCII characters
I agree, it has been added.

>for [IBIS Ver] except substituting CONN for IBIS.
I disagree.  The method we have retains a coupling to the IBIS
group.  Your proposal looses that coupling.

>description since it lists the permitted versus excluded characters.
The existing specification permits characters that would
make the specification unusable.  For example 0,1,2,3,4,5,6,7,8,9 etc
are allowed as comment characters.  I did modify this section to
include the same list of control characters as the IBIS specification.
Also the usage rules have been broken out the same as I am doing
for all the keywords.

>4 lines is not realistic.  Many files have full Copyright statements
The new keywords are parsable meaning that CAE tools can
optimize the way in which it displays the information to a user.  
This was done to improve usability to the end-users and 
should be added to the V3.2 IBIS IC specification as well.

>keyword - e.g., [Reference Designator Map] in an EBD.
If IBIS 3.2 is modified to add support for .ibiscnn it will be easy
to add support for the longer extension.  Shorter 3 character
extensions are no longer being used by many companies as the potential
for collisions with extensions is too high.
There I suggest .ibiscnn is a keeper. 

>5. The [File Rev] rules can be adapted for connector recommending
I agree, I have changed the section to conform with IBIS standards.

>Cn Model Family] description keyword, consistent with usage in IBIS
I agree.  I have moved the [Begin_Cn_Model_Family] above the [Manufacturer]
keyword which is better as it also moves
the associated keywords [Web_Site], [Email],[Redistribution]
to go along with [Manufacturer].

>  by IBIS to be in "derivative" models; the others are recommended.
I strongly disagree.  These are very useful and are parasable.
It cannot be handled with source and notes as it is not parasable
and cannot be presented easily to users by the CAE tool.

>lines.  It is common and well understood for a new keyword to terminate
See comments by Matt, Begin and end are a good thing to do
and there is a precendent in previous IBIS work.

>[Model List] directly under [Begin Cn Model Family] keyword.
I agree, done.

>I would position a single keyword [Description] under each [Begin
I feel this is not as clear as having a specific keyword
[Begin_Cn_Model_Description], I feel it will be somewhat
easier to insure the parser is written correctly knowing
in what context the model description will be and insuring
that it ends up a separate piece of information in the
parsed data base.  All in all I don't feel strongly
either way on this but lean toward having the separate
keyword.  A group vote can resolve this if needed.

>[Begin Cn Phy Map] and [Begin Cn Section]. 
I agree, I have re-organized per your suggestion.