IBIS Connector Specification Editorial Review

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.
Received on Mon Jan 10 14:25:37 2000