To All:
IIRD8.2 containng some editorial revisions is attached to
be considered at the next IBIS Meeting.
Bob
-- Bob Ross Teraspeed Consulting Group LLC Teraspeed Labs 121 North River Drive 13610 SW Harness Lane Narragansett, RI 02882 Beaverton, OR 97008 503-750-6481 503-430-1065 http://www.teraspeed.com 503-246-8048 Direct bob@teraspeed.com
ICM Issue Resolution Document (IIRD)
IIRD ID#: 8.2
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
DATE ACCEPTED BY IBIS OPEN FORUM: PENDING
****************************************************************************
****************************************************************************
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 a unique side
|**** name to allow tools to identify which of the identical pin maps
|**** to make the connection.
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 pin map 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
|**** optional when the node map name is unique.
|** 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
****************************************************************************
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.
****************************************************************************
-----------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with the appropriate command message(s) in the body:
|
| help
| subscribe ibis <optional e-mail address, if different>
| subscribe ibis-users <optional e-mail address, if different>
| unsubscribe ibis <optional e-mail address, if different>
| unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a request to ibis-request@eda.org.
|
|IBIS reflector archives exist under:
|
| http://www.eda.org/pub/ibis/email_archive/ Recent
| http://www.eda.org/pub/ibis/users_archive/ Recent
| http://www.eda.org/pub/ibis/email/ E-mail since 1993
Received on Fri Dec 24 18:53:48 2004
This archive was generated by hypermail 2.1.8 : Fri Dec 24 2004 - 18:55:54 PST