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)
>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.
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.
>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).
.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.
>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.
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.
>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.
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.
>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).
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.
>4. Item 5) in the Connector Specification should be replaced
>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.
>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.
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.
>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.
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.
>7. Item 13) regarding number of decimal points in a number should
>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.
>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.
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
>should be added.
I agree, it has been 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.
I disagree. The method we have retains a coupling to the IBIS
group. Your proposal looses that coupling.
>2. [Comment Char]: I would use the latest IBIS Version 3.2
>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.
>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.
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.
>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.
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
>0.x and 1.x as given.
I agree, I have changed the section to conform with IBIS standards.
>6. The [Manufacturer] keyword should be positioned under the [Begin
>Cn Model Family] description keyword, consistent with usage in IBIS
>Version 3.2 positioning.
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].
>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.
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.
>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.
See comments by Matt, Begin and end are a good thing to do
and there is a precendent in previous IBIS work.
>I would position [Manufacturer], and "[Family Description]" and
>[Model List] directly under [Begin Cn Model Family] keyword.
I agree, done.
>
>I would position a single keyword [Description] under each [Begin
>Cn Model] keyword.
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.
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].
I agree, I have re-organized per your suggestion.
---------------------------------------------------------
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:kellee@hyperlynx.com>
web: <http://www.hyperlynx.com>
---------------------------------------------------------
Received on Thu Jan 13 09:27:25 2000
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:30 PDT