ICM Issue Resolution Document (IIRD) IIRD ID: 6 ISSUE TITLE: [Tree Path Description] Requires Two Pinmaps REQUESTOR: Kelly Green DATE SUBMITTED: August 17, 2004 DATE REVISED: DATE ACCEPTED BY IBIS OPEN FORUM: Rejected October 29, 2004 **************************************************************************** **************************************************************************** STATEMENT OF THE ISSUE: The current text of the [Tree Path Description] keyword is somewhat ambiguous as to whether or not a tree path must both begin and and with a pinmap. The explanitory text several times states that pinmaps are present at both ends, and makes the point that the same pinmap may be used for both ends. All examples show pinmaps at both ends. Yet, at one point in the text, it states that a tree path "must have at least one pinmap", which is confusing. The present 'golden parser' does require that tree paths begin and end with pinmaps. This IIRD resolves the textual ambiguity in favor of the parser. Single ended interconnects cannot be described with this restriction (terminators for example) and should instead use the more general node path description. **************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: ============================================================================= Keyword: [Tree Path Description] Required: Yes, if [Nodal Path Description] does not exist Sub-params: Model_pinmap, Section, Fork, Endfork 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 |* original the interconnect through a conductor. Topologies where physical |* original crossing of one conductor over or under another occurs shall not |* original be described using [Tree Path Description]. |* change the interconnect through a conductor. Single ended topologies |* change such as terminators, or topologies where the physical |* change crossing of one conductor over or under another occurs shall not |* change be described using [Tree Path Description]. The following example is considered legal under a [Tree Path Description]: Pin1 >--------------------------------< Pin2 Pin3 >--------------------------------< Pin4 The following example is considered illegal under a [Tree Path Description]: Pin1 >------------ ------------------< Pin2 \/ /\ Pin3 >------------ ------------------< Pin4 For such a structure, a [Nodal Path Description] (see below) would be more appropriate. Alternately, the pin names can be rearranged to preserve the conductor-to-pin mapping while avoiding physical crossing of conductors, as shown in the following example. Pin1 >--------------------------------< Pin4 Pin3 >--------------------------------< Pin2 These "straight-through" connections allow mapping of conductors to RLGC matrix data by reference to the pins at the endpoints of the individual conductors (the first conductor is represented by the first row of RLGC matrix data, the second conductor by the second row of matrix data, and so on). This description is useful when all of the matrices used in each section can be connected in a conductor by conductor fashion. In all cases, all RLGC matrixes must have the same number of diagonal terms, regardless whether they are swath or full matrices. Further, all diagonal terms must be in the same order. S-parameter data may not be used in combination with the [Tree Path Description] keyword. The [Tree 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. The [Nodal Path Description] and [Tree Path Description] keywords are mutually exclusive and only one of them can be used between a [Begin ICM Model] and [End ICM Model] keyword pair. However, these keywords may appear more than once and may be used together within one file. The [Tree Path Description] keyword line is followed by at least |* original one Model_pinmap and one Section subparameters which describe |* change two 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 |* note are indicated by the "Fork" and "Endfork" subparameters. Tree |* note path descriptions are terminated with a Model_pinmap |* note 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. |* note A second Model_pinmap is used at the end of the path description |* note to reference the pin map used for the other end of the |* note 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. |* note In general, an interconnect will have a single pin map that is |* note referenced at the beginning and end of a path description. Section Following the opening Model_pinmap subparameter is one or more instances of the required subparameter Section. This sub- parameter defines which section matrix is part of this interconnect model. Matrix sections are serially interconnected and may be re-used to form a complete interconnect model. Arguments "multiplier" and "section name" must follow the Section parameter. The "multiplier" argument contains a single numeric value which allows a matrix section to be re-used as a scaled value. This multiplier factor specifies how many times the section should be repeated in series (cascaded) by the EDA tool (the node names therefore represent the ends of the cascaded group of sections). The value of the argument may be any positive value greater than zero. If a section is intended to be repeated (cascaded) a certain amount of times, the syntax of this argument is: Mult = value where "value" must be an integer number. If this argument contains the length of a section, its syntax is: Len = value where "value" is any positive number (see number format rules in Section 3.0). Note that spaces around the "=" sign are not required. Some sections within a particular path description can use Mult while others use Len, if so desired. If "Mult=" is used the [Derivation Method] keyword for the corresponding section must have a value of "Lumped" else it is an error. If "Len=" is used the [Derivation Method] keyword for the corresponding section must have a value of "Distributed" else it is an error. The scale factor "Len" is applied to each parameter of all matrices of a section resulting in scaled RLGC matrices. Mult and Len are separate arguments. Mult and Len are not allowed to be used in the same section. The "section name" is the name of the section as specified under the [Begin ICM Section] keyword. Section may be used as many times as required to describe the interconnect. Each scale factor and section name MUST be separated by at least one space. Fork, Endfork The Fork and Endfork subparameters are used if there are forks or "stubs" in the interconnect being modeled. Fork marks the beginning of the fork/stub while Endfork marks the end of the fork/stub. These subparameters do not have any arguments. At a fork, a path split similar in shape to the letter "T" is created. The matrix sections constituting the "T" are connected, including the first of any sections listed between the Fork and Endfork subparameters. The sections (zero or more) between the Fork and Endfork subparameters are connected together as in any other path description. If no pin map name is placed between a Fork and Endfork block, then the block constitutes a stub. However, if a pin map name is placed at the end of the Fork and Endfork block, an externally available port is created on the interconnect. Any number of Fork subparameters may be used per path description, however only one subparameter is allowed per line. Example: Fork Endfork **************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: The wording of the specification states again and again that pinmaps are at both ends of a tree path, but this is inconsistant with the statement that "at least one pinmap and section" follow the keyword. Tree paths are clearly not meant to describe an arbitrary interconnect, they are intended to handle the relatively simple cases. Node paths are explicitly referenced early on as the preferred way to handle situations that cannot be expressed with a tree path. **************************************************************************** ANY OTHER BACKGROUND INFORMATION: ****************************************************************************