=============================================================================== Issue # : 001 Issue Title : Tab handling Draft Page & Location : page 3 paragraph 1 Classification : Clarification Issue Description : Undefined response to tab characters Old Text : "the use of tab characters is strongly discouraged" Proposed Text or Action : Add the following: If present, TAB characters will be replaced with a sufficient number of spaces to emulate a modulo 8 tab stop. The expansion is counted against the maximum line limit. The parser is expected to issue a warning as well. =============================================================================== Issue # : 002 Issue Title : Empty lines Draft Page & Location : page 3 paragraph 7 Classification : Clarification Issue Description : Undefined response to empty lines Old Text : N/A Proposed Text or Action : Add the following: A line containing nothing but white space is treated as if it were a comment and is ignored. Empty lines may occur anywhere at all in the ICM file. =============================================================================== Issue # : 003 Issue Title : Start character of text strings and blocks Draft Page & Location : page 3-4 paragraph 9 Classification : Clarification Issue Description : It is unclear if leading white space is skipped Old Text : "Text string and file name arguments start on the same line as the keyword and are terminated with a line termination sequence. A text block starts on the same line as the keyword, may extend over multiple lines, and is terminated by the occurrence of the next keyword. Proposed Text or Action : Add the following: Leading white space is skipped before capturing the file name and text strings, as text strings are a form of argument and typically contain names, dates, or other forms of data that do not expect to encounter leading spaces. Leading white space is NOT skipped before capturing a text block. The text block begins immediately following the closing keyword ']'. NOTE: this is existing parser behavior, but it's unspecified, and one has to read the code to see what it does. =============================================================================== Issue # : 004 Issue Title : Comment characters in text strings and blocks Draft Page & Location : page 3-4 paragraph 9 Classification : Clarification Issue Description : Clarify comment behavior Old Text : Add the following: Comment characters are recognized in text block and text strings, with the result that the commented text is removed. In text blocks, if an entire line is commented out, the new line remains. NOTE: this is existing parser behavior. =============================================================================== Issue # : 005 Issue Title : Clarify syntax of standard units Draft Page & Location : page 3-4 paragraph 9 Classification : Clarification Issue Description : Ignore anything following first letter? Old Text : N/A Proposed Text or Action : Add the following: The unit abbreviation following the prefix is not checked in any way. Both kOhm (kilo Ohm) and Mfubar (Mega fubar) are equally valid. You may use scientific notation, standard units, or neither, but not both. =============================================================================== Issue # : 006 Issue Title : Reserved words Draft Page & Location : page 4 paragraph 12 Classification : Clarification Issue Description : A YACC grammar requires additional reserved words Old Text : N/A Proposed Text or Action : The sole purpose of reserved words is to ease the implementation of a parser. It is not possible to construct a YACC grammar for the ICM specification unless additional words are reserved. The essential names are exactly those considered important enough to mention in the tree diagram of section 4. Construction of a YACC grammar to drive the parser has a number of serious advantages, among which is that once the grammar is proved to be correct, the parser compiled from it necessarily implements the grammar faithfully. NOTE: as with the existing reserved words, these additions have no meaning within comments, text strings or text blocks and may be used freely within such. They may not, however, be used as node names, model or section names. ICM_Model_Type SGR Ref_impedance Model_PinMap Fork End_Fork Section Model_NodeMap N_section Left_edge Right_edge Top_edge Bottom_edge Pin_order Num_of_columns Num_of_rows File_name Port_map =============================================================================== Issue # : 007 Issue Title : Clarification of subparameter syntax Draft Page & Location : Throughout the document Classification : Clarification Issue Description : Nothing much is said about subparameter syntax. It's unclear if they must start on their own lines, although every example shows this to be the case and it seems to be the intention. There is a global inconsistency on the use of "=" signs with subparameters. Excepting "Section", subparameters are uniformly described as being followed by a white space separated value of some sort. Yet many examples show the use of an "=" sign. I suspect most of the examples are in fact wrong. Old Text : N/A Proposed Text or Action : 1)Review all subparameters and examples to ensure that "=" is either consistently used (or not) used throughout the document. For the most part it looks like it's the examples that are in error. Other than the Section subparameter, no use of "=" is described or mandated. Alternatively, state globally in the general guidelines that the use of "=" is optional for any subparameter that takes a single value. 2) State in section 3 that subparameters are expected to start on a new line, and may be indented by white space. =============================================================================== Issue # : 008 Issue Title : Errors in tree diagram Draft Page & Location : pages 4-5 Classification : Editorial Issue Description : The [ICM S-parameter] tree diagram is incorrect Old Text : [ICM S-parameter] Pin_order Num_of_columns Num_of_rows Proposed Text or Action : Change to the following: [ICM S-parameter] File_name Port_map =============================================================================== Issue # : 009 Issue Title : Clarification on [date] syntax Draft Page & Location : Page 7 Classification : Clarification Issue Description : Casing of month names Old Text : "Month if fully written out" Proposed Text or Action : Add the following: Months are fully written out with leading capitalization. "January" is valid. "january" is not. =============================================================================== Issue # : 010 Issue Title : Clarification of [Comment Char] behavior Draft Page & Location : page 10 Classification : Clarification Issue Description : "|_char" is not itself a comment Old Text : N/A Proposed Text or Action : Add the following The currently active comment character loses its special significance immediately following a [comment char] keyword. Thus, even if the comment character is currently a "|", "|_char" does not introduce a comment when following the [comment char] keyword. =============================================================================== Issue # : 011 Issue Title : Erroneous keyword [Begin ICM Model Family] Draft Page & Location : Page 10 Classification : Editorial Issue Description : extraneous "Model" in the keyword Old Text : [Begin ICM Model Family] Proposed Text or Action : [Begin ICM Family] This is the only occurrence of [Begin ICM Model Family] in the entire document. The many other references to the keyword are all [Begin ICM Family], including the example for this keyword on this page. =============================================================================== Issue # : 012 Issue Title : Syntax of Family Name Draft Page & Location : Page 10 Classification : Clarification Issue Description : Are white spaces allowed? Old Text : Text String Proposed Text or Action : If the family name is just a text string, then it may include white space. If not, then change this to indicate that a name is expected. Text String(Family Name) =============================================================================== Issue # : 013 Issue Title : Invalid file name examples Draft Page & Location : Page 12 Classification : Editorial Issue Description : All file names in the example use upper case Old Text : N/A Proposed Text or Action : lower case all file names =============================================================================== Issue # : 014 Issue Title : ICM_Model_Type syntax Draft Page & Location : page 13 Classification : Clarification Issue Description : Inconsistent requirement for a single space Old Text : The subparameter and its value are separated by a single white space Proposed Text or Action : Remove this sentence. No other subparameter in the entire document requires "exactly" one space between it and it's value. Multiple spaces should be allowed. =============================================================================== Issue # : 015 Issue Title : SGR argument syntax Draft Page & Location : page 14 Classification : Clarification Issue Description : Is white space allowed? Old Text : The signal to ground ratio is indicated as "number of signal pins per ground pin", followed by a colon (:), followed by the number one (1) Proposed Text or Action : Disregarding the technical adequacy of this parameter, may white space appear around the colon as well? Programmer's preference: Yes. It's simpler to allow white space in general rather than invent a means to suppress it in this particular circumstance. =============================================================================== Issue # : 016 Issue Title : Clarification len=value, mult=value syntax Draft Page & Location : page 15 and page 22 Classification : Clarification Issue Description : Is white space allowed around "="? Old Text : (NOTE that spaces around the "=" are not required) Proposed Text or Action : (NOTE that spaces around the "=" are allowed but not required) =============================================================================== Issue # : 017 Issue Title : Erroneous [Nodal Path Description] examples Draft Page & Location : page 25-26 Classification : Editorial Issue Description : Model_NodeMap subparameter is missing from 6 & 7 Old Text : N/A Proposed Text or Action : Add appropriate "Model_NodeMap" subparameters. =============================================================================== Issue # : 018 Issue Title : *_edge subparameter syntax Draft Page & Location : Page 30 Classification : Editorial Issue Description : Value of subparameter separated by "=" in example Old Text : [ICM Swath Parameters] Left_edge = 1 Right_edge = 1 Top_edge = 0 Bottom_edge = 0 Proposed Text or Action : The description on page 26 does not mention the presence of an "=" between these subparameters and their values, nor does any other subparameter in the entire document require this syntax. Option 1) remove the "=" from the examples. It's probably an error. Option 2) allow an optional "=" between any subparameter and it's value. Option 3) expressly require an "=" between any subparameter and it's value. Option 1) seems the right choice. =============================================================================== Issue # : 019 Issue Title : Missing subparameters for [ICM Swath Pin Numbers]? Draft Page & Location : Page 31 Classification : Clarification Issue Description : Maximum row/column values are needed Old Text : The physical row number consists of an integer value from 1 to the number of rows documented in the [ICM Swath Pin Numbers] keyword. Similarly, the physical column number consists of an integer value from 1 to the number of columns documented in the [ICM Swath Pin Numbers] keyword. Proposed Text or Action : There are no maximum row/column values associated with the [ICM Swath Pin Number] keyword, either on the same line as the keyword, or as subparameters, or in the enclosing [ICM Swath Parameters] keyword. The list of swath pins can be processed to determine the maximum values as used in the list itself. However, if the intention is to discover missing rows, this cannot be relied upon if there are multiple omissions. I suggest that two more subparameters are actually required under the [ICM Swath Parameters] keyword. Num_of_columns integer Num_of_rows integer =============================================================================== Issue # : 020 Issue Title : Inconsistent spelling of "Un-ordered" Draft Page & Location : Page 32, 34 Classification : Editorial Issue Description : page 32 says "Un-ordered", example pg 34 "Un_ordered" Old Text : Proposed Text or Action : Change one or the other. Programmer's preference. Use Un_ordered. Avoid the use of "-", it's inconsistent with the definition of symbolic names, which allow underscore only. =============================================================================== Issue # : 021 Issue Title : Use of "=" in examples Draft Page & Location : Page 34 Classification : Clarification Issue Description : subparameters are shown using "=" Old Text : Num_of_columns = 4 Num_of_rows = 2 | | | Num_of_columns = 4 Num_of_rows = 2 | | | Pin_order = Un_ordered. Proposed Text or Action : Remove the "=" signs, they are NOT specified. =============================================================================== Issue # : 022 Issue Title : Model type is "SLM" Draft Page & Location : Pages 40, 42 and 45 Classification : Editorial Issue Description : There are four SLM_* models Old Text : model type is "SLM" Proposed Text or Action : model type is any "SLM_*" model The document assumes that the reader understands the 'SLM' means any of the available SLM models. =============================================================================== Issue # : 023 Issue Title : Fork Syntax and use Draft Page & Location : Page 17 Classification : Clarification Issue Description : Fork syntax and use is unclear Old Text : N/A Proposed Text or Action : add some or all of the following explanations There appears to be some unstated assumptions in for/end-for usage. 1) fork/end_for must enclose something. It cannot be empty. Thus, although a fork need not enclose either Model_PinMaps or Sections, it must enclose something, which means at least one of either choice. In other words, a fork contains zero-or-more sections followed by an optional Model_PinMap, with the total number of entries being at least ONE. 2) It appears that forks connect to sections. This implies that forks must be surrounded by sections, and cannot be immediately adjacent to either other forks or the endpoint external ports. Eg, P-S-F-S-F-S-P is legal, but P-F.. or ..F-P is not and ..F-F.. is not 3) Ports cannot occur in the middle of an interconnect unless they are encapsulated by a fork/end_fork. Eg, P-S-S-P-S-S-P is illegal, but P-S-S-F-S-S-P is legal | P =============================================================================== Issue # : 024 Issue Title : Treatment of [Comment Char] keyword Draft Page & Location : Page 10 Classification : Clarification Issue Description : Where may this directive appear? Old Text : N/A Proposed Text or Action : Add the following The [Comment Char] keyword may appear anywhere at all in a model file. The sole exception is within a text block, since by definition, text blocks are terminated by the presence of any column 1 "[". Other than that, [comment char] is treated as if it is a whole-line comment, and is replaced with a empty line. =============================================================================== Issue # : 025 Issue Title : Syntax of len= Draft Page & Location : Pages 16 & 22 Classification : Clarification Issue Description : integers may be promoted to real numbers Old Text : ..."where "value" is a floating point decimal real number." Proposed Text or Action : Add the following If the argument is an integer, it is promoted to a real number having an implied decimal point at the right. =============================================================================== Issue # : 026 Issue Title : Use of word "direction" Draft Page & Location : Page 13, Section 7.0 Classification : Editorial Issue Description : The word "direction" is used ambiguously in describing signal transitions in even and odd modes. Old Text : "A value of "SLM_even_mode" indicates that all other neighboring conductors are transitioning at the same time and in the same direction as the conductor being modeled (i.e. under even mode switching conditions). A value of "SLM_odd_mode" indicates that all other neighboring conductors are transitioning at the same time but in the opposite direction as the conductor being modeled (i.e. under odd mode switching conditions)." Proposed Text or Action : ""SLM_even_mode" indicates that all other neighboring conductors are transitioning at the same time and with the same polarity (i.e. low-to-high or high-to-low) as the conductor being modeled (i.e. under even mode switching conditions). "SLM_odd_mode" indicates that all other neighboring conductors are transitioning at the same time as but with opposite polarity to the conductor being modeled (i.e. under odd mode switching conditions)." =============================================================================== Issue # : 027 Issue Title : Use of phrase "multi-line" Draft Page & Location : Page 14, Section 7.0 Classification : Editorial Issue Description : The phrase "multi-line" is used ambiguously in describing s-parameters. This text should be clarified to refer the presence of coupling in the model data and not to exclude single transmission lines. Old Text : "An ICM_Model_Type value of "S-parameter" indicates that this model is a "multi line model" and the electrical data suitable for modeling pin to pin coupling is supplied in a frequency domain format. Specifically, the model is a secondary file in "Touchstone" format." Proposed Text or Action : "An ICM_Model_Type value of "S-parameter" indicates that this model contains frequency domain electrical data suitable for representing single-line behavior or pin-to-pin coupling. The model data is contained in a secondary file in "Touchstone" format." =============================================================================== Issue # : 028 Issue Title : Use of non-zero integers in SGR denominator Draft Page & Location : Page 14, Section 7.0, "SGR" Classification : Clarification Issue Description : The signal-to-ground ratio definition assumes that any interconnect's SGR can be reduced to a single value against the number one (1). This implies that reals are permitted for accurate descriptions of the number of non-ground signals in the interconnect. To avoid the use of repeating reals (1.666666:1 for an interconnect with 5 signals and 3 grounds) or reals with undefined precision (an interconnect with 22 signals and 7 grounds reduces to 3.142857142:1), the requirement for a one (1) in the denominator is removed. Old Text : "If the ICM_Model_Type subparameter is equal to SLM_general, then this SGR subparameter is required. This subparameter specifies the signal to ground ratio used when generating the SLM_general model. The signal to ground ratio is indicated as "number of signal pins per ground pin", followed by a colon (:), followed by the number one (1). For example, if the data for an 18 pin connector was taken with 6 of the pins grounded, the signal to ground ratio is 18/6 or 3 to 1. The SGR subparameter argument would then be listed as 3:1." Proposed Text or Action : "If the ICM_Model_Type subparameter value is SLM_general, then the SGR subparameter is required. This subparameter specifies the signal to ground ratio used when generating the SLM_general model. The signal to ground ratio is indicated by an integer number of signal pins, followed by a colon (:), followed by a non-zero integer (1, 2, etc.) number of ground pins. For example, if the data for an 18 pin connector was taken with 6 of the pins grounded, the signal to ground ratio is 18/6 or 3 to 1. The SGR subparameter argument would then be listed as 3:1. Similarly, if the data for a 22 pin connector was taken with 7 of the pins grounded, the signal to ground ratio would be listed as 22:7. Both the numerator and the denominator values should be as small as possible without inaccurately representing the signal-to-ground ratio." =============================================================================== Issue # : 029 Issue Title : Definition of "port" Draft Page & Location : Whole document, particularly Pages 17 - 22 Classification : Editorial Issue Description : The word "port" is used repeatedly throughout the document but is never actually defined. In addition, the word "pin" is often used where a more general term such as "port" would be more appropriate. Old Text : Proposed Text or Action : Add the following text to the [Tree Path Description] "Description" section: "Note that the text below assumes that the model data describes a connector. Other types of interconnect can be modeled using the [Tree Path Description]; in these cases, the words "pin" and "port" in the text below can be interpreted to refer to the locations where the interconnect is accessed for probing, measurement or analysis." Add the following text to the [Nodal Path Description] "Description" section: "Note that the text below assumes that the model data describes a connector. Other types of interconnect can be modeled using the [Nodal Path Description]; in these cases, the words "pin" and "port" in the text below can be interpreted to refer to the locations or nodes where the interconnect is accessed for probing, measurement or analysis." =============================================================================== Issue # : 030 Issue Title : Clarification of single-ended s-parameter limitation Draft Page & Location : Page 22, Section 7.0, under "N_section" Classification : Clarification Issue Description : [Nodal Path Description]s implicitly exclude mixed-mode s-parameter descriptions such as SDD11, SDD12 and the like. Old Text : "A port for the S-parameter data is defined between a node and the ideal ground." Proposed Text or Action : "A port for the S-parameter data is defined as single-ended, between a node and the ideal ground. Mixed-mode multi-port descriptions (in terms of differential and/or common mode stimuli and responses for groups of ports) are not permitted." =============================================================================== Issue # : 031 Issue Title : Update [Tree Path Description] examples Draft Page & Location : Page 17 - 20; Pages 32 - 33 Classification : Editorial Issue Description : The [Tree Path Description] examples given do not bear any direct relationship to the [ICM Pin Map] examples given later in the document. Old Text : "The examples below use the connector represented by: A1 A2 A3 A4 B1 B2 B3 B4 ----------------------------------------------------------------------------- [ICM Pin Map] Baseboard_side Pin_order = row_ordered Num_of_columns = 4 Num_of_rows = 2 |Pin Type A1 SIG A2 SIG A3 SIG A4 SIG B1 SIG B2 SIG B3 SIG B4 SIG [ICM Pin Map] Baseboard_side2 Pin_order = column_ordered Num_of_columns = 4 Num_of_rows = 2 |Pin A1 SIG B1 SIG A2 SIG B2 SIG A3 SIG B3 SIG A4 SIG B4 SIG [ICM Pin Map] Daughtecard_side Pin_order = Un_ordered |Pin A1 SIG A2 SIG A3 SIG A4 SIG B1 SIG B2 SIG B3 SIG B4 SIG" Proposed Text or Action : "----------------------------------------------------------------------------- The following examples are to be used with the examples following the description of the [Tree Path Description] keyword. ----------------------------------------------------------------------------- |Examples 1 through 5 below use the connector represented by: |A1 A2 A3 A4 |B1 B2 B3 B4 [ICM Pin Map] Example1_pinmap Pin_order = row_ordered Num_of_columns = 4 Num_of_rows = 2 |Pin Type A1 SIG A2 SIG A3 SIG A4 GND B1 SIG B2 SIG B3 SIG B4 GND [ICM Pin Map] MyModelPinMapA Pin_order = column_ordered Num_of_columns = 4 Num_of_rows = 2 |Pin A4 SIG B4 SIG A3 SIG B3 SIG A2 SIG B2 SIG A1 SIG B1 SIG [ICM Pin Map] MyModelPinMapB Pin_order = column_ordered Num_of_columns = 4 Num_of_rows = 2 |Pin A1 SIG B1 SIG A2 SIG B2 SIG A3 SIG B3 SIG A4 SIG B4 SIG [ICM Pin Map] MyModelPinMapC Pin_order = column_ordered Num_of_columns = 4 Num_of_rows = 2 |Pin A1 SIG B1 SIG A2 SIG B2 SIG A3 SIG B3 SIG A4 SIG B4 SIG" =============================================================================== Issue # : 032 Issue Title : Removal of the word "banded" from swath definition Draft Page & Location : Page 27, Section 7.0, "[ICM Swath Parameters]" Classification : Clarification Issue Description : The word "banded" is used to describe the row or column swath matrix without distinguishing it from a "Banded Matrix," which is data defined only relative to and surrounding a matrix diagonal. Old Text : "The model maker decides on the minimum number of columns (for a column swath) or rows (for a row swath) that should be used to define the banded matrix, then assigns values to the appropriate subparameter that will, by subtraction of the columns or rows, create the appropriate maximum matrix size for the swath." Proposed Text or Action : "The model maker decides on the minimum number of columns (for a column swath) or rows (for a row swath) that should be used to define the interconnect matrix, then assigns values to the appropriate subparameter that will, by subtraction of the columns or rows, create the appropriate maximum matrix size for the swath." =============================================================================== Issue # : 033 Issue Title : Clarification of matrix data quality requirement Draft Page & Location : Page 42 - 45 Classification : Clarification Issue Description : The "Matrix Descriptions" text explains that off- diagonal elements in the Maxwellian capacitance matrix will be negative, but never states how negative resistances, negative inductances and the like should be handled. Old Text : Proposed Text or Action : In each of the sections labeled, "Resistance Matrix Description," "Inductance Matrix Description," "Loop-Inductance Matrix Description," "Partial Self Inductance Matrix Description" and "Conductance Matrix Description," add the following text: "Off-diagonal terms must be positive real numbers or zero." In the "Maxwell Capacitance Matrix Description," add the following text: "Off-diagonal terms must be negative real numbers or zero." =============================================================================== Issue # : 034 Issue Title : Revision of statement of intent Draft Page & Location : Page 2, Section 2.0 Classification : Editorial Issue Description : The statement of intent needs significant revision to improve its clarity and grammar, as well as to more clearly distinguish between a "standard," a "template" and a "specification." Old Text : "In order to enable an industry standard method to electronically transport IBIS interconnect modeling data between interconnect design and simulation tools. The intention of this specification is to specify a consistent format that can be parsed by software, allowing simulation vendors to derive models compatible with their own products. One goal of this template is to represent the current state of IBIS data, while allowing a growth path to more complex models / methods (when deemed appropriate). This would be accomplished by a revision of the base template, and possibly the addition of new keywords or categories. Another goal of this template is to ensure that model creation is simple enough for interconnect vendors and customers to use, while ensuring that it is rigid enough for simulation vendors to write reliable parsers. This template is meant to contain a complete description of the elements of an entire interconnect. This specification is intended to provide a basis for future versions which are expected to be backward compatible with this initial version." Proposed Text or Action : "This document is intended to establish a standard method for representing interconnect modeling data for transfer between interconnect design and simulation tools. The text describes a consistent format that can be parsed by software, allowing simulation tool and interconnect vendors to create models compatible with their own products. One goal of this standard is to incorporate the IBIS format and data representation in an initial specification while allowing future growth to include more complex model structures and modeling methods. This will be accomplished through revisions of the base specification to include the addition of new keywords, subparameters and the like. Another goal of this standard is to ensure that model creation is simple enough for interconnect vendors, simulation tool vendors and customers to use, while ensuring rigid enough definitions for simulation tool vendors to write reliable parsers. The standard, as expressed in the current specification, is intended to provide a basis for future revisions, which are expected to be backward compatible with this initial version." =============================================================================== Issue # : 035 Issue Title : Correction of keyword definition Draft Page & Location : Page 3, Section 3.0, Subsection 2 Classification : Editorial Issue Description : The definition of "keyword" used in the specification is grammatically incorrect. Old Text : "Except for keywords (words enclosed by a square bracket [])..." Proposed Text or Action : "Except for keywords (phrases enclosed by a set of square brackets [])..." =============================================================================== Issue # : 036 Issue Title : Correction of "Mating" definition for "Unmated_side_A" Draft Page & Location : Page 11, under "Unmated_side_A" Classification : Editorial Issue Description : The word "socket" was incorrectly used in the place of the word "package." Old Text : "...that is attached to a baseboard, or the socket which holds the socket of an IC." Proposed Text or Action : "...that is attached to a baseboard, or the socket which holds the package of an IC." =============================================================================== Issue # : 037 Issue Title : Identifiers for swath and full interconnect columns Draft Page & Location : Pages 26 - 30 Classification : Editorial Issue Description : The examples and diagrams in this section suffer from the use of numbers to represent both the columns of the swath and the columns of the full interconnect. The text should be changed to use letters for the swath and numbers for the full interconnect. Old Text : (example) " 1 2 3 4 5 *--*--*--*--* |\/|\/|\/|\/| |/\|/\|/\|/\| Swath *--*--*--*--* |\/|\/|\/|\/| |/\|/\|/\|/\| *--*--*--*--* *--*--*--*--*--*--*--*--* |\/|\/|\/|\/|\/|\/|\/|\/| |/\|/\|/\|/\|/\|/\|/\|/\| *--*--*--*--*--*--*--*--* Full Interconnect |\/|\/|\/|\/|\/|\/|\/|\/| |/\|/\|/\|/\|/\|/\|/\|/\| *--*--*--*--*--*--*--*--* 1 2 3 4 5 6 7 8 9 " Proposed Text or Action : (example) " A B C D E *--*--*--*--* |\/|\/|\/|\/| |/\|/\|/\|/\| Swath *--*--*--*--* |\/|\/|\/|\/| |/\|/\|/\|/\| *--*--*--*--* *--*--*--*--*--*--*--*--* |\/|\/|\/|\/|\/|\/|\/|\/| |/\|/\|/\|/\|/\|/\|/\|/\| *--*--*--*--*--*--*--*--* Full Interconnect |\/|\/|\/|\/|\/|\/|\/|\/| |/\|/\|/\|/\|/\|/\|/\|/\| *--*--*--*--*--*--*--*--* 1 2 3 4 5 6 7 8 9 " =============================================================================== Issue # : 038 Issue Title : [ICM Swath Pin Numbers] Example labels Draft Page & Location : Page 30 Classification : Editorial Issue Description : The example under [ICM Swath Pin Numbers] should explicitly show the row and column labels above and to the left of the pin field described. The text should emphasize that the physical pin arrangement is shown. Old Text : "Consider a 2 row by 3 column Swath matrix that was extracted for the pins as shown below: A B C D E F" Proposed Text or Action : "Consider a 2 row by 3 column Swath matrix that was extracted for the pins physically arranged as shown below: C1 C2 C3 R1 A B C R2 D E F" =============================================================================== Issue # : 039 Issue Title : [ICM Swath Parameters] text revisions Draft Page & Location : Pages 26 - 30 Classification : Editorial Issue Description : The text in this section needs significant editing to correct errors in number agreement, poor grammar and hyphenation and use of undefined terms. Old Text : "Description: Describes a smaller matrix which can be used to represent interconnects of equal or larger size. To visualize this, consider the swath matrix being a smaller version of a connector. The edges of the matrix represent the same edge effects that exists in the full size connector. The center area of the matrix represents the same effects as the center of the full size connector. It is the responsibility of the EDA tool to use the matrix and the required keyword information as a "mini" interconnect that is centered about the electrical paths of interest and/or to expand this information into a larger sized swath up to the full sized interconnect itself. For example a 2x8 matrix might be expanded to represent a connector that is 2x100. Usage Rules: Only rectangular interconnects without missing conductor may be represented by a swath matrix. If the interconnect is non- rectangular or the pin field has missing pins then the matrix must describe the full interconnect and this keyword cannot be used. This keyword MUST be present if the number of rows in the matrix does not equal the number of pin names as given by the [ICM Pin Map] keyword used for this model. The [ICM Swath Parameters] keyword may appear multiple times in the file, however it may appear only once between each pair of [Begin ICM Model]/ [End ICM Model] keywords. This keyword is only required when using only a part of the matrix or when expanding the matrix. MUST be followed by 4 required subparameters: 1) Left_edge: Columns in the swath matrix used to represent left edge 2) Right_edge: Columns in the swath matrix used to represent right edge 3) Top_edge: Rows in the swath matrix used to represent top edge 4) Bottom_edge: Rows in the swath matrix used to represent bottom edge These subparameters use the physical representation of the pins to define the minimum coupling bandwidth. The model maker decides on the minimum number of columns (for a column swath) or rows (for a row swath) that should be used to define the banded matrix, then assigns values to the appropriate subparameter that will, by subtraction of the columns or rows, create the appropriate maximum matrix size for the swath. The basic goal is to define how far the edge effects extend into the coupling fields. None of the values of these numbers may exceed the number of rows or column of pins that are defined by the matrices of a given model. The swath is applicable to any model supported by the specification. At this time, there must be at least two subparameters with a value not equal to zero. Please see the example below to see how these are used with the keyword. The edge effects describe the edge rows or columns that do not contain all of the coupling effects (from both sides) that the centermost rows or columns. This information is useful for "swath expansion" when determining what larger size to use. When the swath represents a SLM or else documents all of the pins in a physical interconnect, the off diagonal entries are 0 by convention. If the swath describes a section with fewer columns, but the same number of rows as the physical interconnect, then the row edge effects are 0 by convention. Similarly, if the swath describes a section with fewer rows, but the same number of columns as the physical interconnect, then the column edge effects are 0 by convention. In a fully coupled swath where all pins couple to all others, all of the rows or columns except for the one designated as the centermost row or column can have edge simplification. So the number of rows or columns can extend to all but the center row or column. On the other hand, a coupling pattern that extends over a few columns may result in a smaller number of edges designated. Below is an example of a 3 row by 5 column swath, where the lines in a rectangular connector represent the electrical coupling: *--*--*--*--* |\/|\/|\/|\/| |/\|/\|/\|/\| *--*--*--*--* |\/|\/|\/|\/| |/\|/\|/\|/\| *--*--*--*--* Notice that columns 2, 3, and 4 have the maximum amount of coupling from each side. In this case the edge effect columns 1 and 5 do not have coupling from both sides. Application of Swath Matrices: For the purposes of this discussion a 3 row by 5 column swath is used and the full sized interconnect is 3 rows by 9 columns. The swath matrix data can be organized by [ICM Swath Parameters]. Three methods can be used to apply the Swath matrix information:" Proposed Text or Action : "Description: Describes a smaller matrix which will be expanded by EDA tools to represent interconnects of equal or larger size. Usage Rules: The [ICM Swath Parameters] keyword is only required when only a part of a matrix is to be used or when a matrix is to be expanded to represent a larger interconnect. To visualize this, consider the swath matrix as being a smaller version of a connector. The edges of the swath matrix would represent the edge effects that exist in a full size connector. Similarly, the center area of the swath matrix represents the coupling effects present in the center of the full size connector. Only rectangular interconnects without missing conductors may be represented by a swath matrix. If the interconnect is non- rectangular or the pins within the pin field are missing then the matrix data elsewhere must completely describe the interconnect and this keyword cannot be used. This keyword MUST be present if the number of rows in the matrix does not equal the number of pin names as given by the [ICM Pin Map] keyword used for this model. The [ICM Swath Parameters] keyword may appear multiple times in the file, however it may appear only once between each pair of [Begin ICM Model]/ [End ICM Model] keywords. The keyword MUST be followed by 4 subparameters, each containing integer values: 1) Left_edge: Number of columns in the swath matrix used to represent left edge coupling effects 2) Right_edge: Number of columns in the swath matrix used to represent right edge coupling effects 3) Top_edge: Number of rows in the swath matrix used to represent top edge coupling effects 4) Bottom_edge: Number of rows in the swath matrix used to represent bottom edge coupling effects At least two subparameters must contain non-zero values. The model maker decides on the minimum number of columns (for a column swath) or rows (for a row swath) that can be used to define the full interconnect matrix. The model maker then assigns those values to the corresponding subparameters for the swath. None of the subparameter values may exceed the number of rows or columns defined for the corresponding model's matrix data. If the swath represents an SLM, the off diagonal entries must be 0. If the swath describes a section with fewer columns, but the same number of rows as the physical interconnect, then the row edge effect terms are 0. Similarly, if the swath describes a section with fewer rows, but the same number of columns as the physical interconnect, then the column edge effect terms are 0. Application of Swath Matrices: For the purposes of this example discussion, a 3 row by 5 column swath and a 3 row by 9 column full sized interconnect are used. Three methods can be used to apply the Swath matrix information. Below is an example of a 3 row by 5 column swath, where the lines in a rectangular connector represent the electrical coupling: A B C D E *--*--*--*--* |\/|\/|\/|\/| |/\|/\|/\|/\| *--*--*--*--* |\/|\/|\/|\/| |/\|/\|/\|/\| *--*--*--*--* Notice that columns B, C, and D have the maximum amount of coupling from each side. However, columns A and E are only coupled to one of their sides." =============================================================================== Issue # : 040 Issue Title : [ICM Swath Parameters] expansion rules Draft Page & Location : Pages 26 - 30 Classification : Clarification Issue Description : The text ambiguously describes the mapping process from a swath description to a full-sized connector. As a result, at least three different mappings are possible, depending on the reader's interpretation. The text needs clarification and specific examples, using the lettering from issue #37, should be shown. Old Text : (1) Centering the Swath around the pins of interest 1 2 3 4 5 *--*--*--*--* |\/|\/|\/|\/| |/\|/\|/\|/\| Swath *--*--*--*--* |\/|\/|\/|\/| |/\|/\|/\|/\| *--*--*--*--* *--*--*--*--*--*--*--*--* |\/|\/|\/|\/|\/|\/|\/|\/| |/\|/\|/\|/\|/\|/\|/\|/\| *--*--*--*--*--*--*--*--* Full Interconnect |\/|\/|\/|\/|\/|\/|\/|\/| |/\|/\|/\|/\|/\|/\|/\|/\| *--*--*--*--*--*--*--*--* 1 2 3 4 5 6 7 8 9 ... (a) Copy the left column pattern 1 2 3 4 5 *--*--*--*--* |\/|\/|\/|\/| |/\|/\|/\|/\| Swath *--*--*--*--* |\/|\/|\/|\/| |/\|/\|/\|/\| *--*--*--*--* *--*--*--*--*--*--*--*--* |\/|\/|\/|\/|\/|\/|\/|\/| |/\|/\|/\|/\|/\|/\|/\|/\| *--*--*--*--*--*--*--*--* Full Interconnect |\/|\/|\/|\/|\/|\/|\/|\/| |/\|/\|/\|/\|/\|/\|/\|/\| *--*--*--*--*--*--*--*--* 1 2 3 4 5 6 7 8 9 ... (b) Repeat the center pattern, 1 2 3 4 5 *--*--*--*--* |\/|\/|\/|\/| |/\|/\|/\|/\| Swath *--*--*--*--* |\/|\/|\/|\/| |/\|/\|/\|/\| *--*--*--*--* *--*--*--*--*--*--*--*--* |\/|\/|\/|\/|\/|\/|\/|\/| |/\|/\|/\|/\|/\|/\|/\|/\| *--*--*--*--*--*--*--*--* Full Interconnect |\/|\/|\/|\/|\/|\/|\/|\/| |/\|/\|/\|/\|/\|/\|/\|/\| *--*--*--*--*--*--*--*--* 1 2 3 4 5 6 7 8 9 ... (c) Copy the right column patterns 1 2 3 4 5 *--*--*--*--* |\/|\/|\/|\/| |/\|/\|/\|/\| Swath *--*--*--*--* |\/|\/|\/|\/| |/\|/\|/\|/\| *--*--*--*--* *--*--*--*--*--*--*--*--* |\/|\/|\/|\/|\/|\/|\/|\/| |/\|/\|/\|/\|/\|/\|/\|/\| *--*--*--*--*--*--*--*--* Full Interconnect |\/|\/|\/|\/|\/|\/|\/|\/| |/\|/\|/\|/\|/\|/\|/\|/\| *--*--*--*--*--*--*--*--* 1 2 3 4 5 6 7 8 9 Proposed Text or Action : Add letters under the full interconnect drawings to show the placement of the swath data. Add or change text as shown. (1) Centering the Swath around the pins of interest A B C D E *--*--*--*--* |\/|\/|\/|\/| |/\|/\|/\|/\| Swath *--*--*--*--* |\/|\/|\/|\/| |/\|/\|/\|/\| *--*--*--*--* *--*--*--*--*--*--*--*--* |\/|\/|\/|\/|\/|\/|\/|\/| |/\|/\|/\|/\|/\|/\|/\|/\| *--*--*--*--*--*--*--*--* Full Interconnect |\/|\/|\/|\/|\/|\/|\/|\/| |/\|/\|/\|/\|/\|/\|/\|/\| *--*--*--*--*--*--*--*--* 1 2 3 4 5 6 7 8 9 Note that the swath data is not expanded in this case; the swath simply represents a small portion of the overall interconnect. The tool should not infer data regarding the other columns in the full interconnect in this case. ... (a) Copy the left column pattern A B C D E *--*--*--*--* |\/|\/|\/|\/| |/\|/\|/\|/\| Swath *--*--*--*--* |\/|\/|\/|\/| |/\|/\|/\|/\| *--*--*--*--* *--*--*--*--*--*--*--*--* |\/|\/|\/|\/|\/|\/|\/|\/| |/\|/\|/\|/\|/\|/\|/\|/\| *--*--*--*--*--*--*--*--* Full Interconnect |\/|\/|\/|\/|\/|\/|\/|\/| |/\|/\|/\|/\|/\|/\|/\|/\| *--*--*--*--*--*--*--*--* 1 2 3 4 5 6 7 8 9 A B Mapping of swath data ... (b) Repeat the center pattern, A B C D E *--*--*--*--* |\/|\/|\/|\/| |/\|/\|/\|/\| Swath *--*--*--*--* |\/|\/|\/|\/| |/\|/\|/\|/\| *--*--*--*--* *--*--*--*--*--*--*--*--* |\/|\/|\/|\/|\/|\/|\/|\/| |/\|/\|/\|/\|/\|/\|/\|/\| *--*--*--*--*--*--*--*--* Full Interconnect |\/|\/|\/|\/|\/|\/|\/|\/| |/\|/\|/\|/\|/\|/\|/\|/\| *--*--*--*--*--*--*--*--* 1 2 3 4 5 6 7 8 9 A B C C C Mapping of the swath data Starting at the center of the swath, the coupling pattern of just the center column (swath column C in this example) is copied into the full interconnect matrix being constructed. In this case, the data represented by column C extends forward into the next column of the full interconnect. This process continues by mapping each column of swath data into the full interconnect. In this example, the operation starts at the full interconnect column 3 and ends upon completion at the full interconnect column 7. ... (c) Copy the right column patterns A B C D E *--*--*--*--* |\/|\/|\/|\/| |/\|/\|/\|/\| Swath *--*--*--*--* |\/|\/|\/|\/| |/\|/\|/\|/\| *--*--*--*--* *--*--*--*--*--*--*--*--* |\/|\/|\/|\/|\/|\/|\/|\/| |/\|/\|/\|/\|/\|/\|/\|/\| *--*--*--*--*--*--*--*--* Full Interconnect |\/|\/|\/|\/|\/|\/|\/|\/| |/\|/\|/\|/\|/\|/\|/\|/\| *--*--*--*--*--*--*--*--* 1 2 3 4 5 6 7 8 9 A B C C C C C D E Mapping of the swath data The final step is similar to step (a) above, but applied using the right side of the swath. When the swath is positioned against the right edge of the full interconnect as shown, the data for the rightmost swath columns is copied into the rightmost columns of the full sized interconnect. In this example, the data of swath columns D and E are placed in the full sized interconnect in columns 8 and 9. =============================================================================== Issue # : 041 Issue Title : Pin Map/ Pin List ambiguity Draft Page & Location : page 32/33 Classification : Clarification Issue Description : Start of pin list may be confused with subparameters Subparameters following [Tree Path Description] include 'Pin_order' Un_ordered, Row_ordered, Column_ordered. Required 'Num_of_rows' Required if Pin_order is *_ordered, otherwise absent 'Num_of_columns' Required if Pin_order is *_ordered, otherwise absent Subparameters are immediately followed by a pin list. The problem is this: If the input file is erroneous, say by changing the pin_order from Un_ordered to Column_ordered, and mistakenly omitting the now mandatory Num_of_rows, Num_of_columns subparameters, then one or more rows of the pin list can be misinterpreted as the now required parameters IF pin names are chosen to have the same name as one of the optional row/column subparameters. Yes, this seems a bit far-fetched, but could be easily avoided by marking the start of the pin list with a mandatory subparameter (such as 'Pin_list') which unambiguously establishes the start of the table. This tactic IS used with [ICM S-Parameter], which does flag the start of its port list with a required 'Port_map' subparameter. Old Text : N/A Proposed Text or Action : Add a mandatory subparameter 'Pin_list' to unambiguously mark the start of the pin list table. Alternative: if subparameter names are indeed reserved as requested, then this issue goes away, since it's forbidden to use the subparameter name for a pin at all. It still seems cleaner to add an an unambiguous marker though, even if subparameter names are reserved. =============================================================================== Issue # : 042 Issue Title : Erroneous diagonal matrix example Draft Page & Location : page 48 Classification : Editorial Issue Description : [Row] keywords are required but omitted from the example. The description on page 40 is quite explicit about this. A diagonal matrix is expressed exactly like a banded matrix of bandwidth 1. Old Text : [Begin ICM Section] ExampleMatrix00 [Derivation Method] Distributed [Resistance Matrix] Diagonal_matrix 10.0 15.0 15.0 10.0 10.0 15.0 15.0 10.0 [End ICM Section] ExampleMatrix00 Proposed Text or Action : Change to the following [Begin ICM Section] ExampleMatrix00 [Derivation Method] Distributed [Resistance Matrix] Diagonal_matrix [Row] 1 10.0 [Row] 2 15.0 [Row] 3 15.0 [Row] 4 10.0 [Row] 5 10.0 [Row] 6 15.0 [Row] 7 15.0 [Row] 8 10.0 [End ICM Section] ExampleMatrix00