                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:



****************************************************************************



