BIRD36.1 Comments

Stephen:

As discussed in the Packaging Subcommittee meeting on Friday, February 28,
1997, I wanted to submit some comments on BIRD36.1. Below are some
editorial and technical comments that reflect some revised thinking.

1. Editorial: Under "Contents:" Capitalize [File Name], [File Rev],
    and [Comment Char].

2. Editorial: Under [Pin List], Description:, change to read
    "Tells the parser the pin names of the user accessible pins."

3. Editorial: Under [Path Description], should "who's" be "whose"?

4. Editorial: Under [Path Description], Usage Rules:, change
    ".. a sections electrical properties .." to ".. electrical properties
    of a section ..".

5. Editorial: Under [Path Description], SECTION DESCRIPTION SUBPARAMETERS,
    Len, I prefer to use "interpreted" instead of "treated". Also, see 10
    below.

6. Editorial: Under [Path Description], SECTION DESCRIPTION SUBPARAMETERS,
    L, change "3.0nH" to "3.0 nH" and "1.5nH" to "1.5 nH".

7. Technical: Under [Path Description], SECTION DESCRIPTION SUBPARAMETERS,
    Node, I prefer to have verbiage stating that the Node references the
    pin of a component or the pin of an electrical board description
    contained in a .ibs or .ebd file. See 12 below.

8. Technical: Under [Path Description], SECTION DESCRIPTION SUBPARAMETERS,
    Pin, after some thought, I believe it is possible to state that each
    signal pin (other than POWER, GND, or NC) must be named once and only
    once within all of the [Path Description]s of the [Begin Board
    Description] keyword. The POWER, GND and NC pins may optionally be
    named once. This rule will make it easier for the file checking utility
    to detect description errors. Furthermore, it might be noted that the
    pin names do not have to occur in the same order as they appear in the
    [Pin List] table.

9. Editorial: Under [Path Description], Using The Subparameters to Describe
    Paths:, the last sentence should delete the "(/)" reference since it is
    already defined in the paragraph.

10. Editorial: Under [Path Description], Using The Subparameters to Describe
    Paths:, last sentence of second paragraph, I would prefer using
    "interpreted" for "treated" as in 5. above.
   
11. Editorial: Under [Path Description], A DESCRIPTION USING THE FORK AND
    ENDFORK SUBPARAMETERS, Add n and spacing changes and slash to change
    the line to
      
      "Len = 1.0 L=1.0n C=2.0p /"

    Also three lines below, change "l = 6.0n" to "L=6.0n".

12. Technical: Under [Reference Designator Map], Add text and change the
    example to add an additional column for component name or board
    description name since both the .ibs and .ebd files can contain
    multiple occurrences of components or board descriptions. The new
    column may follow the part reference column.
    
    Also, I have a problem with allowing actual path descriptions in a
    STANDARDIZED file description. All of the .ibs and .ebd files should
    be contained in the same directory - at least as a DEFAULT. Simulator
    specific editors can work with allowing name substitutions and more
    complicated path descriptions.

    One problem is that a specific 80286.ibs component may come from different
    vendors and carry different component names and be stored in different
    directories. The difference between traditional DOS and UNIX directory
    structure notation makes this an operating system-specific, simulator
    specific-issue and installation-specific issue. Furthermore, the path
    descriptions along with the other columns could, in practice, cause columns
    to exceed the 80 characterter width limit. Simulators may allow such
    exceptions including arbitrary path description lengths, but for
    standardization and transportability of files, this should not be allowed.

    Forcing the specification of a specific (default) component at this time
    will eliminate some future practical problems that many components come
    in different package configurations with different pin numbers (e.g.,
    PLCC and PGA). A generic specification "80286.ibs" is to ambiguous for
    future needs and will just lead to application errors.

    Question: Can there be multiple occurrences of the same reference
    designator (e.g., u23 for 80286.ibs and u23 for abc286.ibs)? The
    first occurrence could be the default, but the additional occurrences
    may be available as selection options.
    
    Finally, the example shows u26, R10K. That should be a .ibs file.

Overall, you did a nice job in capturing into BIRD36.1 a very workable
format for describing boards. I look forward to voting on this as soon
as some to the issues above are resolved.

Bob Ross
Interconnectix

 
Received on Mon Mar 3 07:50:42 1997