ICM Issue Resolution Document (IIRD) IIRD ID#: 8.3 ISSUE TITLE: Distinct Model_pinmap and Model_nodemap Names REQUESTOR: Bob Ross, Teraspeed Consulting Group DATE SUBMITTED: September 22, 2004 DATE REVISED: November 21, 2004, December 24, 2004, January 13, 2005 DATE ACCEPTED BY IBIS OPEN FORUM: January 28, 2005 **************************************************************************** **************************************************************************** STATEMENT OF THE ISSUE: Model_pinmap and Model_nodemap names under [Tree Path Description] and [Nodal Path Description] need to be distinct to allow interfacing with IBIS or other types of connections. If the names are reused, then a method is needed for EDA tools to identify the specific name for connections. **************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Statements are added that the Model_pinmap and Model_nodemap names must either be distinct or else differentiated by a new subparameter "Side" under [Tree Path Description] and [Nodal Path Description]. Change instruction lines are identified by |** Changes are identified by |*, |***, |**** lines. Some unchanged portions are omitted. |** MODIFY THE TREE DIAGRAM IN THE PORTION BELOW |--/--[Begin ICM Family] | (see Chapter 7) | | |--[Manufacturer] | | |--[ICM Family Description] | | |--[ICM Model List] | | | |--/--[Begin ICM Model] | | | | ICM_model_type | | | | SGR | | | | Ref_impedance | | | |--[ICM Model Description] | | | |--[Tree Path Description] | | | | Model_pinmap |** Add this line | | | | Side |** End of addition | | | | Fork, Endfork | | | | Section | | | |--[Nodal Path Description] | | | | Model_nodemap |** Add this line | | | | Side |** End of addition | | | | N_section | | | |--[ICM Swath Parameters] | (optional, for swaths) | | | | Left_edge | | | | Right_edge | | | | Top_edge | | | | Bottom_edge | | | |--[ICM Swath Pin Numbers] | (optional, for swaths) | | \--[End ICM Model] | | | |--[ICM Pin Map] | Pins to Physical | | Pin_order | | Num_of_columns | | Num_of_rows | | Pin_list | |--[ICM Node Map] | Nodes to Physical | \--[End ICM Family] | |** MAKE CHANGES TO THE [Tree Path Description] KEYWORD SHOWN BELOW: ============================================================================= Keyword: [Tree Path Description] Required: Yes, if [Nodal Path Description] does not exist |** Delete this line Sub-params: Model_pinmap, Section, Fork, Endfork |** Add this line Sub-params: Model_pinmap, Side, Section, Fork, Endfork |** End of addition Used By: [Begin ICM Model] Uses: [ICM Pin Map] Description: This keyword describes the connection path between the pin or pins on one side of the interconnect and the corresponding set of pins on the other side. This pin to pin interconnect is divided into one or more "sections", where each section consists of RLGC data. Sections are generally cascaded in series, but the Fork and Endfork subparameters allow sections to branch off the main interconnect path as a stub or tee. Usage Rules: A [Tree Path Description] is used when all of the sections in a given interconnect have one-to-one mapping. In other words, each pin is electrically connected to at least one other pin of the interconnect through a conductor. Topologies where physical crossing of one conductor over or under another occurs shall not be described using [Tree Path Description]. |** Several paragraphs are omitted ..... The [Tree Path Description] keyword line is followed by at least one Model_pinmap and one Section subparameters which describe the pin-to-conductor mapping, and the topology of the interconnect. The electrical properties of an interconnect section are described in the matrices under the [Begin ICM Section] keyword which are referenced by the Section subparameter(s), discussed below. Branches or "T" connections are indicated by the "Fork" and "Endfork" subparameters. Tree path descriptions are terminated with a Model_pinmap subparameter. These subparameters are described in detail below. Model_pinmap A path description begins with the required subparameter Model_pinmap. This subparameter is followed by the name of a "pin map" which names the pins on that end of the interconnect. A second Model_pinmap is used at the end of the path description to reference the pin map used for the other end of the interconnect. The Model_pinmap subparameter can also be used to reference a pin map for the pins at the end of any Fork. Note that the pin map name given as an argument to a Model_pinmap subparameter must match the name of a pin map defined by a subsequent [ICM Pin Map] keyword. The argument to the Model_pinmap subparameter and the sub- parameter itself are separated by whitespace. There can be as many Model_pinmap subparameters as required, but each must be on a single line. |* Delete this paragraph: In general, an interconnect will have a single pin map that is referenced at the beginning and end of a path description. |** Replace with this paragraph: |**** One or more Model_pinmap lines can exist, but each pin map |**** name must be unique and reference a different [ICM Pin Map] |**** description even if the content is dentical. Alternatively, |**** the same Model_pinmap may be used, but the subparameter Side |**** described below must follow next. |** End of replacement paragrapth |** Add new sub-section Side |**** If a Model_pinmap pin map name is repeated within a [Tree Path Description] keyword, the Side subparameter is required and positioned as the next line under the Model_pinmap |**** subparameter. The Side subparameter is followed by a unique side |****** name. This side name identifies a specific pin map connection |****** from several with the same name. The Side subparameter is required for all Model_pinmap lines with identical pin map names. The Side subparameter is optional when the pin map name is unique. |** End of sub-section addition |** MODIFY THE EXAMPLE AS SHOWN BELOW ----------------------------------------------------------------------------- "ICM Model" Examples ----------------------------------------------------------------------------- Example 1: A simple single line model with one section SectA Port1 >--------< Port2 [Begin ICM Model] MyModelExample1 ICM_model_type SLM_general SGR 3:1 Ref_impedance=50 [Tree Path Description] Model_pinmap Example1_pinmap |** Add these lines Side A | The Model_pinmap name is reused, so Side and a unique | side name is required |** End of addition Section Mult=1 Diagonal_matrix1 Model_pinmap Example1_pinmap |** Add these lines Side B | The Model_pinmap name is reused, so Side and a unique | side name is required |** End of addition . . . [End ICM Model] |** Remainder of the Example is omitted ... |** MAKE CHANGES TO THE [Nodal Path Description] KEYWORD SHOWN BELOW: ============================================================================= Keyword: [Nodal Path Description] Required: Yes, if [Tree Path Description] does not exist |** Delete this line Sub-params: N_section, Model_nodemap |** Add this line Sub-params: N_section, Model_nodemap, Side |** End of addition Used By: [Begin ICM Model] Uses: [ICM Node Map] Description: This keyword marks the beginning of a nodal path description. It contains the information on how two or more nodes are connected. The nodal description style allows for any arbitrary topologies to be described. Nodes define the connection points where the conductors of two or more sections are joined together, or where the path is interfaced to the outside world. Please note that single connections (dangling ends) at nodes are also permitted. Thus nodes can represent any connection points, including pins (on either side of connectors, packages, or sockets), pads and bumps of a die (where the connections to the package or printed circuit board are made), or the ends of either side of interconnect sections of printed circuit boards. An interconnect path may have one or more sections where each section is described by RLGC or S-parameter matrices. Multiple sections within a path description may be connected in any arbitrary manner by using the usual node naming techniques. Please note that the swath features cannot be used with this keyword. Also note that the use of both RLGC and S-parameter matrix data for sections within the same [Nodal Path Description] is prohibited. Usage Rules: The [Nodal Path Description] 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. |** Several paragraphs are omitted ..... Model_nodemap The required subparameter Model_nodemap is used to reference the [ICM Node Map] keyword which provides a mapping between the actual data book pin (or signal) names and the node names used in the path description. A path description must have at least one occurrence of the required subparameter Model_nodemap, but can have as many Model_nodemap subparameters as needed to adequately describe the interconnect. The number of Model_nodemap subparameters used in a path description would be typically the same as the number of ends or sides in a connector or interconnect. Each Model_nodemap subparameter must be on a single line. The Model_nodemap subparameter is followed by one argument, which the name of a node map. The argument must match the name of a node map defined by a subsequent [ICM Node Map] keyword. The argument and the subparameter must be separated by at least one white space. |** Add this paragraph: |**** One or more Model_nodemap lines can exist, but each node map |**** name must be unique and reference a different [ICM Node Map] |**** description even if the content is identical. Alternatively, |**** the same Model_nodemap may be used, but the subparameter Side |**** described below must follow next. |** End of added paragraph |** Add new sub-section Side |****** If a Model_nodemap node name is repeated within a [Nodal Path Description] keyword, the Side subparameter is |**** required and positioned as the next line under the |**** Model_nodemap subparameter. The Side subparameter is followed |**** by a unique side name to allow tools to identify which of the |**** identical node maps to make the connection. The Side subparameter is required for all Model_nodemap lines |**** with identical node map names. The Side subparameter is |****** followed by a unique side name. This side name identifies a |****** specific node map connection from several with the same name. |** End of sub-section addition **************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Originally it was assumed that if the pinout at each end of an interconnect such as a connector had the same pin numbers, then the same [ICM Pin Map] table could be used as referenced by the Model_pinmap. However, this leads to ambiguous begin-end conditions for straight through paths and possible ambiguity for splitter topologies possible in both the Tree Path Description] and [Nodal Path Description] when a specific end needs to be connected externally. So unique Model_pinmap and Model_nodemap names are explicitly specified to assist in the correct connection. This prepares ICM for a possible IBIS BIRD to connect IBIS with ICM using the multi-lingual format. The language is not changed regarding possible single Model_pinmap and Model_nodemap lines. And Unmated model will have a single Model_*map line. IIRD8.1: A new subparameter "Side" is introduced so that the same Model_pinmap name can be used several times without requiring coping an entire [ICM Pin Map] table. It is also introduced for Model_nodemap for the same reason. This option was chosen among the following: (1) Do nothing - NO syntax change, compatible with 1.0 wasteful for large connectors (2) Devise an extension convention Example1_A, EXample1_B ... Example1/A. Extension may conflict with an actual naming convention. (3) Introduce Optional subparameter or second column OR single SPACE Example1 Side A or Example1 A However, calling routine must work with/without extension. (4) Perhaps introduce in the [ICM Pin Map] and [ICM Node Map] a) multiple names b) Another_name xxxxx subparameter syntax Option (3) with a distinct subparameter Side is chosen as as the method that is consistent with the rest of the specification. IIRD8.2 Some editorial changes per Arpad Muranyi's comments are made and noted by |**** lines IIRD8.3 Some minor editorial changes suggested by Arpad Murnayi noted by |****** lines. (correction of pin to node, and rewriting of the last sentence in two paragraphs.) **************************************************************************** ANY OTHER BACKGROUND INFORMATION: IIRD8 assumes that IIRD6 will be rejected. The golden parser must be corrected to accept only one Model_*map or else test that the arguments of several are unique. IIRD8 was discussed at the October 29, 2004 IBIS meeting and the Novemeber 4, 2004 IBIS Futures Meeting. The action item was to investigate a better method of differentiating the terminals by some name, extension or name and subparameter to avoid the need to provide large, identical pin tables. IIRD8.3 was approved at the January 28, 2005 IBIS Open Forum meeting, with the addition of the word "by" before "a unique side name" under the Side description under [Tree Path Description]. ****************************************************************************