Subject: IBIS Draft Responses to Letter Ballot

From: Bob Ross <[email-masked]>
Date: Fri, 30 Jul 1999 10:03:15 -0700

To IBIS Members:

We approved the DRAFT responses to the Mentor Graphics and Anigma, Inc.
letter ballot on SP-4557 at the July 23, 1999.  We will consider approval
of the Intel Corporation and Cisco Systems responses documented in the
July 23, 1999 Minutes at the next IBIS meeting scheduled for Friday,
August 6, 1999.

We will also consider the responses to the letter ballot comments
submitted by SiQual, Inc.  These are included below for your review.

We may revise our DRAFT responses to some comments based on our discussion
at the meeting.

Bob Ross
Mentor Graphics

*******************************************************************************

EIA IBIS COMMITTEE RESPONSE TO SIQUAL, INC. COMMENTS TO STANDARDS PROPOSAL
NO. 4557

SiQual: 1
Editorial
Reference: Section 3, "GENERAL SYNTAX RULES AND GUIDELINES", paragraph 1

Suggested Change:

Change From:

| 1)  The content of the files is case sensitive, except for reserved
|     words and keywords.  File names must be all lower case.

To (delete last sentence):

| 1)  The content of the files is case sensitive, except for reserved
|     words and keywords.

Rationale:
The file name restriction is redundant, and should be covered
only in paragraph 3, which pertains to file names.

Response: We agree with this Suggested Change.

SiQual: 2
Editorial
Reference: Section 3, "GENERAL SYNTAX RULES AND GUIDELINES", paragraph 3

Suggested Change:

Change From:

| 3)  File names used in the IBIS file must only have lower case characters to
|     enhance UNIX compatibility.  File names should have a basename of no
|     more than twenty characters followed by a period, followed by a file
|     name extension of no more than three characters.  File names must not
|     contain characters that are illegal in DOS.

To:  (shorten first sentence, replace third sentence) 

| 3)  File names used in the IBIS file must only have lower case characters.
|     File names should have a basename of no more than twenty characters
|     followed by a period ('.') , followed by a file name extension of no
|     more than three characters.  The file name and extension must use
|     characters from the set (space, ' ', 0x20 is not included):
|
|             A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
|             a b c d e f g h i j k l m n o p q r s t u v w x y z
|             0 1 2 3 4 5 6 7 8 9 _ ^ $ ~ ! # % & - { } ) ( @ ' `
|  
|     The file name and extension are recommended to be lower case on
|     systems that support such names.

Rationale:

  1) References to specific software or products is not precise.

  2) The phrase "to enhance UNIX compatibility" is wrong.

  3) The phrase "illegal in DOS" is not defined.

  4) The "golden parser" code allows the following characters in file names
     The allowed character set is currently defined by the "golden parser"
     as (the space character, ' ', 0x20 is not included):

        A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
        a b c d e f g h i j k l m n o p q r s t u v w x y z
        0 1 2 3 4 5 6 7 8 9 _ ^ $ ~ ! # % & - { } ) ( @ ' ` .

     Note:  the illegal characters are therefore:

        SP(0x20) " * + , / : ; < = > ? [ \ ] | DEL(0x7F)

     The period '.' should not be allowed, as it is specified as the
     file name/extension delimiter.

  5) From "hdr.c" (part of the "golden parser", no version info in file)

/* DOS restrictions */
      if (!isalpha(*pc) && !isdigit(*pc) && (*pc != '_') &&
         (*pc != '^') && (*pc != '$') && (*pc != '~') && (*pc != '!') &&
         (*pc != '#') && (*pc != '%') && (*pc != '&') && (*pc != '-') &&
         (*pc != '{') && (*pc != '}') && (*pc != ')') && (*pc != '(') &&
         (*pc != '@') && (*pc != '\'') && (*pc != '`') && (*pc != '.'))
{
         ERRLOG_LineError(
    "File_name '%s' contains a character '%c' that is illegal for DOS.",
         pHdr->sFile_name, *pc);
      }

Response: We agree with this Suggested Change.

SiQual: 3
Editorial
Reference: Section 3, Section 3, "GENERAL SYNTAX RULES AND GUIDELINES",
paragraph 6

Suggested Change:

Change From:

| 6)  Keywords must be enclosed in square brackets, [], and must start in
|     column 1 of the line.

To:  (add additional sentences)

| 6)  Keywords must be enclosed in square brackets, [], and must start in
|     column 1 of the line.  No space or tab is allowed after the opening
|     bracket '[' or before the closing bracket ']'.  If used, only one
|     space (' ') or underscore ('_') character separates the parts of a
|     multi-word keyword.

Rationale:

This is not specified by the standard, but is enforced by the "golden
parser."  If required, this behavior should be spelled out in the standard.

Response: We agree with this Suggested Change, but with the following
additional clarifications: Change "after" to "immediately after" and
"before" to "immediately before".

SiQual: 4
Editorial
Reference: Section 3, "GENERAL SYNTAX RULES AND GUIDELINES", paragraph 14

Suggested Change:

Change From:

| 14) Only ASCII characters, as defined in ANSI Standard X3.4-1986, may be
|     used in an IBIS file.  The use of characters with codes greater than
|     hexadecimal 07F is not allowed.  Also, ASCII control characters
|     (those numerically less than hexadecimal 20) are not allowed, except
|     for tabs or in a line termination sequence. As mentioned in item 10
|     above, the use of tab characters is discouraged.

To:  (change second sentence)

|                     . . .  The use of characters with codes greater than
|     hexadecimal 07E is not allowed.  . . .

Rationale:

The ASCII character DEL (0x7F) is not consistently implemented across
systems.  It is often non-printable, and when printed, is not the
same on different systems.

Response: We agree with this Suggested Change.

SiQual: 5
Editorial
Reference: Section 4, "FILE HEADER INFORMATION", Keyword:  [File Name]

Suggested Change:

Change From:

| Usage Rules:  The file name must not be longer than 24 characters (including
|               the extension).  The file name must not use characters that
|               are illegal in DOS.  In addition, the file name must be all
|               lower case, and use the extension ".ibs".  The file name must
|               be the actual name of the file.

To:  (replace first two sentences, change third sentence)

| Usage Rules:  The file name must conform to the rules in paragraph 3 of
|               Section 3, "GENERAL SYNTAX RULES AND GUIDELINES."  In
|               addition, the file name must use the extension ".ibs",
|               ".pkg", or ".ebd".  The file name must be the actual
|               name of the file.

------------------------------------------------------------------------------
Rationale:

  1) File naming rules must be consistent and defined only in one place.
     Specifically, Section 3, "GENERAL SYNTAX RULES AND GUIDELINES" 
        para 1: defines case of file names as all lower (this should move
                to para 3)
        para 3: defines filename length and format as twenty
                character name + period + three character extension

  2) To be consistent with Section 7, "PACKAGE MODELING" and section 8,
     "ELECTRICAL BOARD DESCRIPTION", the ".pkg" and ".ebd" must be
      allowed.

Response: We agree with this Suggested Change.

SiQual: 6
Editorial
Reference: Section 4, "FILE HEADER INFORMATION", Keyword:  [Comment Char]

Suggested Change:

Change From:

| Usage Rules:  The new comment character to be defined must be followed by
|               the underscore character and the letters "char".  For example:
|               "|_char" redundantly redefines the comment character to be
|               the pipe character.  The new comment character is in effect
|               only following the [Comment Char] keyword.  The following
|               characters MAY NOT be used:  A B C D E F G H I J K L M N O P
|               Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u
|               v w x y z 0 1 2 3 4 5 6 7 8 9 [ ] . _ / = + -

To:  (change last sentence)

|                                                     . . . The following
|               characters MAY be used:
|
|                     ! " # $ % & '     * , : ; < > ? @   ^ `   |   ~ 

Rationale:

  1) For clarity, definition of a limited set of characters should
     be terms of those allowed, not those disallowed. 

  2) Based on the current wording and paragraph 14 of section three,
     the allowed [Comment Char] list is (ASCII hex shown first):

     | 20 SP | 21  ! | 22  " | 23  # | 24  $ | 25  % | 26  & | 27  ' |
     | 28  ( | 29  ) | 2A  * |       | 2C  , |       |       |       |
     |       |       |       |       |       |       |       |       |
     |       |       | 3A  : | 3B  ; | 3C  < |       | 3E  > | 3F  ? |
     | 40  @ |       |       |       |       |       |       |       |
     |       |       |       |       |       |       |       |       |
     |       |       |       |       |       |       |       |       |
     |       |       |       |       | 5C  \ |       | 5E  ^ |       |
     | 60  ` |       |       |       |       |       |       |       |
     |       |       |       |       |       |       |       |       |
     |       |       |       |       |       |       |       |       |
     |       |       |       | 7B  { | 7C  | | 7D  } | 7E  ~ | 7F DEL|

     Of this list:

        0x20 'SP'           - is wrong
        0x7F 'DEL'          - is inconsistently implemented across systems
        0x5C '\'            - is commonly used as an escape meta-character
        0x28 '(', 0x29 ')'  - paired delimiters should be reserved for future
        0x7B '(', 0x7D ')'       use by the standard

  3) The "golden parser" program 'ibischk3' implements per the standard:
     From "parse.c" (part of the "golden parser", no version info in file)

/* list of chars that cannot be the comment char */
static char  gpcBadCommChars[] =
   "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ[]._/=+-";

Response: We that the permitted comment characters should be listed as
suggested.  However, since the `\', `(', `)', `{', and `}' characters
are already permitted by the standard and by the ibischk3 parser code,
we are including them in the list.  We may consider reducing the number
of permitted comment characters in IBIS Version 4.0.  The amended list is

|                 ! " # $ % & ' ( ) * , : ; < > ? @ \ ^ ` { | } ~ 

SiQual: 7
Editorial
Reference: Section 5, "COMPONENT DESCRIPTION"; [Component] keyword,
           Sub-Param Usage Rules, paragraph 3

Suggested Change:

Change From:

|                            . . .  The default location is at the 'Pin'.
|               However, the 'Die' location is also available for either or
|               and both subparameters.

To (shorten existing second sentence, then insert new second sentence):

|                            . . .  Allowed values for either sub-parameter
|               are 'Die' or 'Pin'.  The default location is at the 'Pin'.

Rationale:

Clarification of wording.

Response: We agree with this Suggested Change.

SiQual: 8
Editorial
Reference:  Section 6a, "ADD SUBMODEL DESCRIPTION";
            sub-section "SUBMODEL:", paragraph 4

Suggested Change:

Change From:

< Move paragraph 4 and list of keywords to the [Submodel] keyword description >

| The following set of keywords that are defined under the [Model] keyword are
| support by the [Submodel] keyword:
|
| [Pulldown]
| [Pullup]
| [GND Clamp]
| [POWER Clamp]
| [Ramp]
| [Rising Waveform]
| [Falling Waveform]

To (correct spelling of "supported" in first sentence, add new paragraph):

| The only required subparameter in [Submodel] is Submodel_type to define the
| list of submodel types.  The other subparameters under [Model] are not
| permitted under the [Submodel] keyword.
|
| The following set of keywords that are defined under the [Model] keyword are
| supported by the [Submodel] keyword:
|
| [Pulldown]
| [Pullup]
| [GND Clamp]
| [POWER Clamp]
| [Ramp]
| [Rising Waveform]
| [Falling Waveform]

| At least one of the [Pulldown], [Pullup], [GND Clamp], [POWER Clamp] is    <
| required.  If the [Submodel] describes a driver, the [Ramp] keyword is     <
| required.                                                                  <

Rationale:

The initial text is redundant, since the proper location is in the [Submodel]
keyword description.  The additional paragraph stipulates that some reason
must exist for a [Submodel] definition.

Response: We agree with this Suggested Change.

SiQual: 9
Editorial
Reference: Section 6a, "ADD SUBMODEL DESCRIPTION"; keyword [Submodel];
           Sub-Param Usage Rules, paragraph _

Suggested Change:

Change From:

|                                                               . . .  The
|               submodel name must match the one that is listed under the
|               [Add Submodel]

To (in second sentence, change "under the" to "under a"):

|                                                               . . .  The
|               submodel name must match the one that is listed under a
|               [Add Submodel] keyword . . .

Rationale:

The wording is not correct.

Response: We agree with this Suggested Change.