IBIS Connector Specification Technical Comments

To IBIS Committee:

Thank you for the comments and responses to the editorial review.
Some of the points will be discussion items at the next meeting.

One main purpose is to get concensus on the content. Differences
should be highlighted, rather than slipped in unnoticed. Then
a deliberate decision by the group should be made with respect
to the features. Our goal is to stablize the document and syntax
to a sufficient extent to initiate a parser development project.

Bob Ross
Mentor Graphics

This is the beginning of a technical review. I expect to do more
techical review later.

1. [Begin_Cn_Model_Family]
   Should there be a family_name?

   I do not see any reason why we need to limit this to one family per
   file. While in practice this might be the case for Connector
   suppliers, this might not be convenient for designers who want
   to store or export models of all connectors in a design into
   a single file.

2. [Begin_Cn_Model_List]
   Regarding "Max_Slew_Time", do you really mean max slew rate and
   "Min_Slew_Time"?

   While the Connector Committee debated this point, I am wondering
   if the image files could just be "recommended" as .jpg or .txt formats.
   The statement "may be either" must be changed to "must be either"
   or else "is recommended to be either". New formats might emerge.

3. [Begin_Cn_Model]
   Does the optional SNR need to be restricted to SLM? Could the format
   be generalized to "a:b" such as for 5:2. Are the numbers restricted
   to integers? Is there a need for a limit (e.g. 100:1.)

   I would prefer a syntax of the form:

     "[Begin_Cn_Model] ModelName"

   and then have the other entries as subparameters. We already have
   a conflict with having the "required" ModelPinMap and ModelPhyMap
   entries that would not be used if [Begin_Cn_Auto_Map] is used. Also,
   the single name argument is more consistent with all the IBIS keywords
   for named sections (e.g., [Component], [Model], [Define Package Model],
   [Begin Board Description], [Submodel]).

   Can the syntax:

     "Cn_Section SectionA SectionB SectionC .. "

   be supported in a manner parallel to

     "Cn_Stub Stub1 Stub2 ..."

   that is also a series connection of stubs?

4. Item 12) in syntax rules and [Cn_Number_of_Conductors]
   Is there a need to limit the size of the conductors to 100000. I would
   just let real designs decide the limit? There is no tecnical
   reason why more than 100000 conductors can be supported.

   I do not have a alternative proposal, but I would like to avoid multi-
   choice arguments. The argument for this keyword is either a positive
   integer or a range, e.g, "9 to 25". Is 9to25 allowed? 9 TO 25?,
   25 to 9?, etc. All of these would need to be tested.
   
   The same comment applies for [Cn_Columns_of_Pins] integer or VARIABLE
   (uppercase only). The syntax is inconsistent with [Cn_Rows_of_Pins]
   which does not allow VARIABLE. While there is no technical limit,
   there does not seem to be the need to introduce a new data type for
   each keyword. It seems that this range and "variable" choice
   information is best positioned in the [Begin_Cn_Auto_Map] keyword or
   in some manner that is self-checking.

5. [Begin_Cn_Auto_Map].
   The equation methodology for Index, Pin and Signal seems powerful.
   However, there seems to be an opportunity to make a mistake and
   create indicies that repeat, if improper equations are entered.
   We need to review this further since there is an interaction with
   fixed equations and some of the numerical choices that could be
   entered (e.g, if [Cn_Rows_of_Pins] were change from 2 to 3 in the
   first example.

   Also, it is not clear that a specific entry would be passed into the
   model for the "VARIABLE" in order to produce the specific connector
   of interest. The parameter passing mechanism needs to be better
   defined than just a "VARIABLE" where critical information regarding
   the acceptable values of VARIABLE are buried within the model itself.

   The autogeneration syntax seems to be well thought out, but still needs
   review.
Received on Wed Jan 12 17:11:56 2000