[ibis-macro] IBIS-ICM interfacing BIRD draft...
- From: "Mirmak, Michael" <michael.mirmak@xxxxxxxxx>
- To: <ibis-interconn@xxxxxxxxxxxxx>, "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 21 Jan 2008 15:40:15 -0800
Please find enclosed what I believe to be an easily-implemented way to
link ICM and IBIS for package modeling purposes. Also enclosed is a ZIP
file containing several examples; these will not work error-free under
the 4.2 parser, but should only show an error regarding a [Package
Model] reference to an ICM file (see below).
The good news: the draft BIRD makes *no syntax changes to IBIS or ICM at
all*, except to the [Package Model] keyword (and then only to permit
.icm as a legitimate filename extension).
[Pin Mapping] is supported as-is and integrates nicely with ICM
packages. ICM may also be used directly to express power supply paths
as well as signal paths.
Half of the text is simply copying the original specification, so that
the changes are obvious. The biggest change is the addition of a new
section, "NOTES ON CONNECTING IBIS AND ICM MODELS." Some slight text
changes are made to [Circuit Call] to remove the oblique references to
ICM in the original document and to clarify implicit pad naming.
The bad news: this does not enable 1-to-many or many-to-1 pad-to-pin
connections under traditional IBIS. If you want to create stacked die
structures, wired-or packages or other exotic connections, you have to
use a multi-lingual format (either [External Model] or [External
Circuit]). This *does* enable much better package and power supply
interconnect modeling under traditional IBIS, so I believe the lack of
stacked die support is more than compensated.
To my knowledge, no conflicts with existing keywords exist in this BIRD
and the ambiguities of Figure 12 and [Circuit Call] have been removed
with this approach. No interactions or overrides for [Algorithmic
Model], [Series Pin Mapping] or [Diff Pin] are involved, to my
knowledge. Similarly, none of our recent measurement proposals should
be affected in any way by this BIRD.
Note: some of you saw a slightly different draft, sent earlier. Please
replace that one with this one.
As always, comments, questions and suggestions are welcome. I hope that
this, plus the additional measurement parameters under discussion, can
be reviewed and adopted quickly for inclusion in IBIS 5.0.
- MM
<<bird-icm-interfacing-draft-simplified.txt>>
<<icm-ibis-examples.zip>>
******************************************************************************
******************************************************************************
BIRD ID#: XXX
ISSUE TITLE: Package Modeling with ICM
REQUESTER: Michael Mirmak, Intel Corp.
DATE SUBMITTED: January 18, 2008
DATE REVISED:
DATE ACCEPTED BY IBIS OPEN FORUM: PENDING
******************************************************************************
******************************************************************************
STATEMENT OF THE ISSUE:
The IBIS specification, versions 1.1 through 4.2, includes a native package
modeling format which extends package representations beyond lumped
parameters. This native format can describe package interconnects through
multi-segment uncoupled topologies or through a single matrix for coupling
information. This native format assumes that the [Pin] keyword describes
and assigns 1-to-1 connections between buffers ([Model]s) and pins.
The ICM (IBIS Interconnect Modeling) Specification was introduced in 2003 to
permit modeling of more complex packages, including lossy coupled and
frequency-domain descriptions. No explict links between IBIS and ICM exist at
this time in either specification.
The IBIS 4.1 specification, under the [Circuit Call] keyword definition,
includes references to a "non-native package model" format. This format was
intended to enable explicit (named) connections of die pads to package pins,
as well as to permit package routing topologies not possible using IBIS
[Package Model] syntax (e.g., connecting multiple die pads to a single
package pin).
At the time of adoption of IBIS 4.1, the details of this "non-native" format
were not decided and ICM was not an official specification. Additionally, the
specific method for attaching "non-native" package models to IBIS was unknown.
As a result, the IBIS 4.1 parser does not support models which rely on package
connections under this "non-native" format.
This BIRD updates the IBIS specification to support ICM as the "non-native"
format described in IBIS 4.1. ICM support is enabled here under both the
multi-lingual and "native" IBIS approaches. This update also enables multi-
lingual IBIS [Component]s to use multiple package connections to a single pin
and/or a
single buffer. Note that this BIRD changes little about the actual syntax of
IBIS, but implies that additional checking of referenced ICM files is required
to ensure correct linking of ICM and IBIS files.
******************************************************************************
STATEMENT OF THE RESOLVED SPECIFICATIONS:
All changes, with the exception of spacing and line break adjustments, are
shown with |*.
|*****************************************************************************
|* ORIGINAL [PACKAGE MODEL] TEXT
|*****************************************************************************
|=============================================================================
| Keyword: [Package Model]
| Required: No
| Description: Indicates the name of the package model to be used for the
| component.
| Usage Rules: The package model name is limited to 40 characters. Spaces
| are allowed in the name. The name should include the company
| name or initials to help ensure uniqueness. The EDA tool
| will search for a matching package model name as an argument
| to a [Define Package Model] keyword in the current IBIS file
| first. If a match is not found, the EDA tool will next look
| for a match in an external .pkg file. If the matching package
| model is in an external .pkg file, it must be located in the
| same directory as the .ibs file. The file names of .pkg files
| must follow the rules for file names given in Section 3,
| GENERAL SYNTAX RULES AND GUIDELINES.
| Other Notes: Use the [Package Model] keyword within a [Component] to
| indicate which package model should be used for that
| component. The specification permits .ibs files to contain
| [Define Package Model] keywords as well. These are described
| in the "Package Modeling" section near the end of this
| specification. When package model definitions occur within a
| .ibs file, their scope is "local", i.e., they are known only
| within that .ibs file and no other. In addition, within that
| .ibs file, they override any globally defined package models
| that have the same name.
|-----------------------------------------------------------------------------
[Package Model] QS-SMT-cer-8-pin-pkgs
|
|*****************************************************************************
|* ORIGINAL [CIRCUIT CALL] DESCRIPTION TEXT
|*****************************************************************************
| Port_map:
|
| The Port_map subparameter is used to connect the ports of an
| [External Circuit] to die nodes or die pads.
|
| Every occurrence of the Port_map subparameter must begin on a
| new line and must be followed by two arguments, the first
| being a port name, and the second being a die node, die pad,
| or a pin name.
|
| The first argument of Port_map must contain a port name that
| matches one of the port names in the corresponding [External
| Circuit] definition. No port name may be listed more than
| once within a [Circuit Call] statement. Only those port names
| need to be listed with the Port_map subparameter which are
| connected to a die node or a die pad. This includes reserved
| and/or user-defined port names.
|
| The second argument of the Port_map subparameter contains
| the name of a die node, die pad, or a pin. The names of die
| nodes, die pads, and pins may appear multiple times as
| Port_map subparameter arguments within the same [Circuit
| Call] statement to signify a common connection between
| multiple ports, such as common voltage supply.
|
| Please note that a pin name in the second argument does not
| mean that the connection is made directly to the pin. Since
| native IBIS does not have a mechanism to declare die pads
| explicitly, connections to die pads are made through their
| corresponding pin names (listed under the [Pin] keyword).
| This convention must only be used with native IBIS package
| models where a one-to-one path between the die pads and pins
| is assumed. When a package model other than native IBIS is
| used with a [Component], the second argument of Port_map must
| have a die pad or die node name. These names are matched to
| the corresponding port name of the non-native package model by
| name (not by position). In this case, the package model may
| have an arbitrary circuit topology between the die pads and
| the pins. A one-to-one mapping is not required.
|-----------------------------------------------------------------------------
| Examples:
|-----------------------------------------------------------------------------
|
| NOTE REGARDING THIS EXAMPLE:
| The pad_* to pin connections in Figure 12 and in the example
| lines with the comment, "explicit pad connection", are shown for
| reference. The connection syntax has not yet been defined.
| Therefore, the connections for pad_* to pin are not supported
| in this specification.
|
| For the examples below please refer to the following diagram and the
| example provided for the [Node Declarations] keyword.
|
| Component Die Package Pins/balls
|-------------------------------------------------------+ +-------+
| | | |
| [E.Circuit] [E.Circuit] | | |
| +-------------------------+ +--------------+ | | |
| | Model_A A_mypcr-+-a-+-vcca1 vcc-+-10-----+-+--@@@--o 10 Vcc
| | |\ A_mypur-+-b-+-vcca2 | | | |
| |D_drive--| >---+-A_mysig-+-c-+-int_ioa io1-+-1------+-+--@@@--o 1 Buffer A
| |D_enable-|/ /| | A_mypdr-+-d-+-vssa1 | | | |
| |D_receive--< |-+ A_mygcr-+-e-+-vssa2 gnd-+-pad_11-+-+--@@@--o 11 GND
| | \| | | | | | |
| +-------------------------+ | Die_ | | | |
| | Interconnect | | | |
| [E.Circuit] | | | | |
| +-------------------------+ | | | | |
| | Model_B | | | | | |
| | |\ A_mypur-+-f-+-vccb1 | | | | Self Ad-
| |D_drive--| >-----A_mysig-+-g-+-int_ob o2-+-pad_2a-+-+-@@@-+-o 2 justing
| | |/ A_mypdr-+-h-+-vssb1 | | | | | Buffer
| | |A_mycnt | | | | | | |
| +----------+--------------+ +--------------+ | | | |
| | Analog Buffer Control | | | |
| +-----------------------------------pad_2b-+-+-@@@-+ |
| | | |
| [E.Circuit] | | |
| +--------------------------+ | | |
| | Model_C A_mypcr-+-10---(to pin/pad 10) | | |
| | |\ A_mypur-+-10---(to pin/pad 10) | | |
| nd1-+-D_mydrv--| >---+-A_mysig-+-3--------------------+-+--@@@--o 3 Buffer C
| | | D_enable-|/ /| | A_mypdr-+-pad_11 | | |
| | | D_receive--< |-+ A_mygcr-+-pad_11 | | |
| | | \| | | | |
| | +--------------------------+ | | |
| | | | |
| | [E.Circuit] | | |
| | +--------------------------+ | | |
| | | Model_D | | | |
| | | /| A_mypcr-+-10---(to pin/pad 10) | | +-@@@-o 4a Clocka
| nd1-+-D_receive--< |---A_mysig-+-pad_4----------pad_4-+-+-+ |
| | \| A_mygcr-+-pad_11 | | +-@@@-o 4b Clockb
| +--------------------------+ | | |
| | | |
| [E.Model] inside [Model] | | |
| +-----------------------------+ | | |
| | Model_E A_pcref-+-> | | |
| | |\ A_puref-+-> | | |
| | D_drive--| >---+---A_signal-+-------------------+-+--@@@--o 5 Buffer E
| | D_enable-|/ /| | A_pdref-+-> | | |
| | D_receive--< |-+ A_gcref-+-> | | |
| | \|---A_external-+-> | | |
| | A_gnd-+-> | | |
| +-----------------------------+ | | |
|-------------------------------------------------------+ +-------+
|
| Notes:
| 1) The ports of the [External Model] E are automatically connected by
| the tool, taking the [Pin Mapping] keyword into consideration, if exists.
| 2) The package model shown in this drawing assumes the capabilities of a
| non-native IBIS package model are available to the model author.
|
| Figure 12
|
|
[Circuit Call] A | Instantiates [External Circuit] named "A"
|
Signal_pin 1
|
| mapping port pad/node
|
Port_map A_mypcr a | Port to internal node connection
Port_map A_mypur b | Port to internal node connection
Port_map A_mysig c | Port to internal node connection
Port_map A_mypdr d | Port to internal node connection
Port_map A_mygcr e | Port to internal node connection
|
[End Circuit Call]
|
|
[Circuit Call] B | Instantiates [External Circuit] named "B"
|
Signal_pin 2
|
| mapping port pad/node
|
Port_map A_mypur f | Port to internal node connection
Port_map A_mysig g | Port to internal node connection
Port_map A_mypdr h | Port to internal node connection
Port_map A_mycnt pad_2b | Port to explicit pad connection
|
[End Circuit Call]
|
|
[Circuit Call] C | Instantiates [External Circuit] named "C"
|
Signal_pin 3
|
| mapping port pad/node
|
Port_map A_mypcr 10 | Port to implicit pad connection
Port_map A_mypur 10 | Port to implicit pad connection
Port_map A_mysig 3 | Port to implicit pad connection
Port_map A_mypdr pad_11 | Port to explicit pad connection
Port_map A_mygcr pad_11 | Port to explicit pad connection
Port_map D_mydrv nd1 | Port to internal node connection
|
[End Circuit Call]
|
|
[Circuit Call] D | Instantiates [External Circuit] named "D"
|
Signal_pin 4a
|
| mapping port pad/node
|
Port_map A_my_pcref 10 | Port to implicit pad connection
Port_map A_my_signal pad_4 | Port to explicit pad connection
Port_map A_my_gcref pad_11 | Port to explicit pad connection
Port_map D_receive nd1 | Port to internal node connection
|
[End Circuit Call]
|
|
[Circuit Call] Die_Interconnect | Instantiates [External Circuit] named
| "Die_Interconnect"
|
| mapping port pad/node
|
Port_map vcc 10 | Port to implicit pad connection
Port_map gnd pad_11 | Port to explicit pad connection
Port_map io1 1 | Port to implicit pad connection
Port_map o2 pad_2a | Port to explicit pad connection
Port_map vcca1 a | Port to internal node connection
Port_map vcca2 b | Port to internal node connection
Port_map int_ioa c | Port to internal node connection
Port_map vssa1 d | Port to internal node connection
Port_map vssa2 e | Port to internal node connection
Port_map vccb1 f | Port to internal node connection
Port_map int_ob g | Port to internal node connection
Port_map vssb1 h | Port to internal node connection
|
[End Circuit Call]
|
|*****************************************************************************
|* END ORIGINAL TEXT
|*****************************************************************************
|*****************************************************************************
|* NEW [PACKAGE MODEL] TEXT
|*****************************************************************************
|
|=============================================================================
| Keyword: [Package Model]
| Required: No
| Description: Indicates the name of the package model to be used for the
| component.
|* Usage Rules: Package models may be in IBIS or in ICM (IBIS Interconnect
|* Modeling) format. The package model name is limited to 40
| characters. Spaces are allowed in the name. The name should
| include the company name or initials to help ensure uniqueness.
| The EDA tool will search for a matching package model name as
| an argument to a [Define Package Model] keyword in the current
| IBIS file first. If a match is not found, the EDA tool will
| next look for a match in an external .pkg or .icm file. If the
|* matching package model is in an external .pkg or .icm file, it
|* must be located in the same directory as the .ibs file.
|* If both a .pkg and a .icm file containing a matching model
|* are found, the .icm definition is assumed to take precedence.
|* The file names of .pkg and .icm files must follow the rules for
| file names given in Section 3, GENERAL SYNTAX RULES AND
GUIDELINES.
| Other Notes: Use the [Package Model] keyword within a [Component] to
| indicate which package model should be used for that
| component. The specification permits .ibs files to contain
| [Define Package Model] keywords as well. These are described
|* in the Section 7, PACKAGE MODELING. However, while ICM
|* syntax may be used in external .icm files to describe package
|* models, ICM syntax is not permitted under the
|* [Define Package Model] keyword or anywhere else within an IBIS
|* file.
|*
|* When package model definitions occur within a
| .ibs file, their scope is "local", i.e., they are known only
| within that .ibs file and no other. In addition, within that
| .ibs file, they override any globally defined package models
| that have the same name.
|-----------------------------------------------------------------------------
[Package Model] QS-SMT-cer-8-pin-pkgs
|
|*****************************************************************************
|* NEW [CIRCUIT CALL] TEXT
|*****************************************************************************
|
| Port_map:
|
| The Port_map subparameter is used to connect the ports of an
| [External Circuit] to die nodes or die pads.
|
| Every occurrence of the Port_map subparameter must begin on a
| new line and must be followed by two arguments, the first
| being a port name, and the second being a die node, die pad,
| or a pin name.
|
| The first argument of Port_map must contain a port name that
| matches one of the port names in the corresponding [External
| Circuit] definition. No port name may be listed more than
| once within a [Circuit Call] statement. Only those port names
| need to be listed with the Port_map subparameter which are
| connected to a die node or a die pad. This includes reserved
| and/or user-defined port names.
|
| The second argument of the Port_map subparameter contains
| the name of a die node, die pad, or a pin. The names of die
| nodes, die pads, and pins may appear multiple times as
| Port_map subparameter arguments within the same [Circuit
| Call] statement to signify a common connection between
| multiple ports, such as common voltage supply.
|
|* Note that a pin name in the third column does not
|* mean that the connection is made directly to the pin. In
|* such a case, the die pad of the buffer connected to the pin
|* is named implicitly, by referring to the buffer's
|* corresponding pin name (listed under the [Pin] keyword). In
|* other words, a pin name in the third column names a pad
|* which is associated to a [Pin] of the same name. The interconnect
|* between the pad and [Pin] is defined by appropriate package
|* method: [Pin], [Package] or [Package Model].
|*
|* DELETE TEXT BELOW
|* Please note that a pin name in the second argument does not
|* mean that the connection is made directly to the pin. Since
|* native IBIS does not have a mechanism to declare die pads
|* explicitly, connections to die pads are made through their
|* corresponding pin names (listed under the [Pin] keyword).
|* This convention must only be used with native IBIS package
|* models where a one-to-one path between the die pads and pins
|* is assumed. When a package model other than native IBIS is
|* used with a [Component], the second argument of Port_map must
|* have a die pad or die node name. These names are matched to
|* the corresponding port name of the non-native package model by
|* name (not by position). In this case, the package model may
|* have an arbitrary circuit topology between the die pads and
|* the pins. A one-to-one mapping is not required.
|* END DELETION
|-----------------------------------------------------------------------------
| Examples:
|-----------------------------------------------------------------------------
|
|* DELETE TEXT BELOW
|* NOTE REGARDING THIS EXAMPLE:
|* The pad_* to pin connections in Figure 12 and in the example
|* lines with the comment, "explicit pad connection", are shown for
|* reference. The connection syntax has not yet been defined.
|* Therefore, the connections for pad_* to pin are not supported
|* in this specification.
|* END DELETION
|
| For the examples below please refer to the following diagram and the
| example provided for the [Node Declarations] keyword.
|
| Component Die Package Pins/balls
|-------------------------------------------------------+ +-------+
| | | |
| [E.Circuit] [E.Circuit] | | |
| +-------------------------+ +--------------+ | | |
| | Model_A A_mypcr-+-a-+-vcca1 vcc-+-10-----+-+--@@@--o 10 Vcc
| | |\ A_mypur-+-b-+-vcca2 | | | |
| |D_drive--| >---+-A_mysig-+-c-+-int_ioa io1-+-1------+-+--@@@--o 1 Buffer A
| |D_enable-|/ /| | A_mypdr-+-d-+-vssa1 | | | |
| |D_receive--< |-+ A_mygcr-+-e-+-vssa2 gnd-+-pad_11-+-+--@@@--o 11 GND
| | \| | | | | | |
| +-------------------------+ | Die_ | | | |
| | Interconnect | | | |
| [E.Circuit] | | | | |
| +-------------------------+ | | | | |
| | Model_B | | | | | |
| | |\ A_mypur-+-f-+-vccb1 | | | | Self Ad-
| |D_drive--| >-----A_mysig-+-g-+-int_ob o2-+-pad_2a-+-+-@@@-+-o 2 justing
| | |/ A_mypdr-+-h-+-vssb1 | | | | | Buffer
| | |A_mycnt | | | | | | |
| +----------+--------------+ +--------------+ | | | |
| | Analog Buffer Control | | | |
| +-----------------------------------pad_2b-+-+-@@@-+ |
| | | |
| [E.Circuit] | | |
| +--------------------------+ | | |
| | Model_C A_mypcr-+-10---(to pin/pad 10) | | |
| | |\ A_mypur-+-10---(to pin/pad 10) | | |
| nd1-+-D_mydrv--| >---+-A_mysig-+-3--------------------+-+--@@@--o 3 Buffer C
| | | D_enable-|/ /| | A_mypdr-+-pad_11 | | |
| | | D_receive--< |-+ A_mygcr-+-pad_11 | | |
| | | \| | | | |
| | +--------------------------+ | | |
| | | | |
| | [E.Circuit] | | |
| | +--------------------------+ | | |
| | | Model_D | | | |
| | | /| A_mypcr-+-10---(to pin/pad 10) | | +-@@@-o 4a Clocka
| nd1-+-D_receive--< |---A_mysig-+-pad_4----------pad_4-+-+-+ |
| | \| A_mygcr-+-pad_11 | | +-@@@-o 4b Clockb
| +--------------------------+ | | |
| | | |
| [E.Model] inside [Model] | | |
| +-----------------------------+ | | |
| | Model_E A_pcref-+-> | | |
| | |\ A_puref-+-> | | |
| | D_drive--| >---+---A_signal-+-------------------+-+--@@@--o 5 Buffer E
| | D_enable-|/ /| | A_pdref-+-> | | |
| | D_receive--< |-+ A_gcref-+-> | | |
| | \|---A_external-+-> | | |
| | A_gnd-+-> | | |
| +-----------------------------+ | | |
|-------------------------------------------------------+ +-------+
|
| Notes:
| 1) The ports of the [External Model] Model_E are automatically connected by
| the tool, taking the [Pin Mapping] keyword into consideration, if exists.
|* DELETE TEXT BELOW
|* 2) The package model shown in this drawing assumes the capabilities of a
|* non-native IBIS package model are available to the model author.
|* END DELETION
|
| Figure 12
|
|
[Circuit Call] Model_A | Instantiates [External Circuit] named "A"
|
Signal_pin 1
|
| mapping port pad/node
|
Port_map A_mypcr a | Port to internal node connection
Port_map A_mypur b | Port to internal node connection
Port_map A_mysig c | Port to internal node connection
Port_map A_mypdr d | Port to internal node connection
Port_map A_mygcr e | Port to internal node connection
|
[End Circuit Call]
|
|
[Circuit Call] Model_B | Instantiates [External Circuit] named "B"
|
Signal_pin 2
|
| mapping port pad/node
|
Port_map A_mypur f | Port to internal node connection
Port_map A_mysig g | Port to internal node connection
Port_map A_mypdr h | Port to internal node connection
Port_map A_mycnt pad_2b | Port to explicit pad connection
|
[End Circuit Call]
|
|
[Circuit Call] Model_C | Instantiates [External Circuit] named "C"
|
Signal_pin 3
|
| mapping port pad/node
|
Port_map A_mypcr 10 | Port to implicit pad connection
Port_map A_mypur 10 | Port to implicit pad connection
Port_map A_mysig 3 | Port to implicit pad connection
Port_map A_mypdr pad_11 | Port to explicit pad connection
Port_map A_mygcr pad_11 | Port to explicit pad connection
Port_map D_mydrv nd1 | Port to internal node connection
|
[End Circuit Call]
|
|
[Circuit Call] Model_D | Instantiates [External Circuit] named "D"
|
Signal_pin 4a
|
| mapping port pad/node
|
Port_map A_my_pcref 10 | Port to implicit pad connection
Port_map A_my_signal pad_4 | Port to explicit pad connection
Port_map A_my_gcref pad_11 | Port to explicit pad connection
Port_map D_receive nd1 | Port to internal node connection
|
[End Circuit Call]
|
|
[Circuit Call] Die_Interconnect | Instantiates [External Circuit] named
| "Die_Interconnect"
|
| mapping port pad/node
|
Port_map vcc 10 | Port to implicit pad connection
Port_map gnd pad_11 | Port to explicit pad connection
Port_map io1 1 | Port to implicit pad connection
Port_map o2 pad_2a | Port to explicit pad connection
Port_map vcca1 a | Port to internal node connection
Port_map vcca2 b | Port to internal node connection
Port_map int_ioa c | Port to internal node connection
Port_map vssa1 d | Port to internal node connection
Port_map vssa2 e | Port to internal node connection
Port_map vccb1 f | Port to internal node connection
Port_map int_ob g | Port to internal node connection
Port_map vssb1 h | Port to internal node connection
|
[End Circuit Call]
|
|*=============================================================================
|* NOTES ON CONNECTING IBIS AND ICM MODELS
|* IBIS Interconnect Modeling (ICM) Specification Models may be used as package
|* models, if the associated files are properly referenced under the [Package
Model] keyword.
|* In order to assure correct connection of the model, a specific nodal
|* naming syntax must be followed. Please refer to version 1.1 of the ICM
|* Specification for details on the ICM keywords mentioned below.
|*
|* In all cases described below, the IBIS [Component] that uses ICM to describe
|* its package interconnect simply includes a legal ICM filename under the
[Package Model] keyword.
|* The named ICM file must include pins and/or nodes named according to the
rules below
|* to ensure proper connections are made by the EDA tool. Parsing by the ICM
parser of
|* the calling IBIS file is not assumed.
|*
|* Connections Using [Pin] and [Model] without [External Model]
|*
|* Package connections using ICM between pins named under the IBIS [Pin]
keyword and the individual
|* buffer pads used by instances of [Model] may be accomplished only
implicitly,
|* where a single buffer is assumed connected to the named pin without itself
|* having a distinct name.
|*
|* Connections are made using the [ICM Node Map] or [ICM Pin Map] keywords. A
specific
|* [ICM Node Map]/[ICM Pin Map] keyword section must be present and match the
[Pin]
|* list of the associated IBIS model by name. Similarly, a specific
|* [ICM Node Map]/[ICM Pin Map] keyword section must be present and match the
pad
|* names from the associated IBIS model by name. Pad names are determined
|* from the [Pin] name.
|*
|* Note that simply identifying the pad of interest is not sufficient to
|* fully specify an interconnect definition. As even traditional
|* IBIS models have ports for power, ground supplies, etc., the pad side
|* of the associated ICM model must also specify the IBIS port name of interest.
|* Therefore, the naming scheme in [ICM Pin Map]s to be used in connecting to
IBIS is:
|*
|* a) The [ICM Pin Map] for the component side connecting to the external world
uses IBIS [Pin]
|* names under the first (Pin) column
|* b) The [ICM Pin Map] for the die side of the component uses the syntax
Pin_name.port_name, where
|* the period character separates the IBIS pin name (which is an implied pad
name in traditional
|* models) and the associated port_name or [Pin Mapping] rail (see below)
|*
|* Similarly, the naming scheme in [ICM Node Map]s to be used in connecting to
IBIS is:
|*
|* a) The [ICM Node Map] for the component side connecting to the external
world uses IBIS [Pin]
|* names under the first (Pin) column
|* b) The [ICM Node Map] for the die side of the component uses the syntax
Pin_name.port_name,
|* where the period character separates the IBIS pin name (which is an
implied pad name in
|* traditional models) and the associated port_name or [Pin Mapping] rail
(see below)
|*
|* For the signal pad and only the signal pad, the .port_name portion of the
[ICM Node Map] or [ICM Pin Map]
|* is omitted.
|*
|* Note that the IBIS [Pin] is matched to pin name (first column) and not the
node name (second column) in [ICM Node Map].
|*
|* For both [ICM Node Map] and [ICM Pin Map], specific string arguments must be
used as names in order
|* to clearly identify the association between the IBIS and ICM nodes, pins
and/or pads.
|* The word "Die" must be used for the die pad side (buffer side) and "Pin" for
the pin/ball side (connected
|* outside of the component). The terms are case-sensitive.
|*
|* The Side subparameter may be used but is not required. Additional [ICM Node
Map]s, [ICM Pin Map]s
|* and/or Side subparameters will be assumed to be unconnected.
|*
|* Where [Pin Mapping] is used, the rails named there are assumed to be ideal
or shorted
|* connections between on-die nodes. Therefore, the port_name used above must
match the name
|* of a [Pin Mapping] rail in cases where ICM is used to model the package of
an IBIS [Component]
|* using [Pin Mapping].
|*
|* If [Pin Mapping] is not used, the supplies for individual models may still
be connected to the ICM
|* package. In this case, the "port_name" above must be one of the following
strings:
|* pulldown_ref, pullup_ref, gnd_clamp_ref, power_clamp_ref, ext_ref. In this
way, the supply nodes
|* for each model may be uniquely identified and connected through an ICM
package.
|*
|* The ICM package does not have to connect to every port or pin described in
the
|* IBIS component.
|*
|* Connections Using [Pin] and [Model] with [External Model]
|*
|* Connections of ICM to IBIS [Component]s featuring [External Model] calls are
made in a similar
|* fashion to those involving traditional [Model]s.
|*
|* Therefore, the naming scheme in [ICM Pin Map]s to be used in connecting to
IBIS is:
|*
|* a) The [ICM Pin Map] for the component side connecting to the external world
uses IBIS [Pin]
|* names under the first (Pin) column
|* b) The [ICM Pin Map] for the die side of the component uses the syntax
Pin_name.port_name, where
|* the period character separates the IBIS pin name (which is an implied pad
name in traditional
|* models) and the associated port_name or [Pin Mapping] rail (see below)
|*
|* Similarly, the naming scheme in [ICM Node Map]s to be used in connecting to
IBIS is:
|*
|* a) The [ICM Node Map] for the component side connecting to the external
world uses IBIS [Pin]
|* names under the first (Pin) column
|* b) The [ICM Node Map] for the die side of the component uses the syntax
Pin_name.port_name,
|* under the first (Pin) column, where the period character separates the
IBIS pin name
|* (which is an implied pad name in traditional models) and the associated
port_name or
|* [Pin Mapping] rail (see below)
|*
|* As above, for both [ICM Node Map] and [ICM Pin Map], specific string
arguments must be used as names in order
|* to clearly identify the association between the IBIS and ICM nodes, pins
and/or pads.
|* The word "Die" must be used for the die pad side (buffer side) and "Pin" for
the pin/ball side (connected
|* outside of the component). The terms are case-sensitive.
|*
|* Support for [Pin Mapping] with [External Model] is similar that for
traditional [Model].
|* Where [Pin Mapping] is used, the rails named there are assumed to be ideal
or shorted
|* connections between on-die nodes. Therefore, the port_name used above must
match the name
|* of a [Pin Mapping] rail in cases where ICM is used to model the package of
an IBIS [Component]
|* using [Pin Mapping].
|*
|* If [Pin Mapping] is not used, the analog ports for individual models may
still be connected to the ICM
|* package. In this case, the "port_name" above must be one of the following
strings, corresponding to
|* [External Model] reserved analog ports: A_puref, A_pcref, A_pdref, A_gcref,
A_extref, A_gnd.
|*
|* Note that A_signal is assumed to be the signal pad itself. Therefore, ICM
connections to the signal pad omit
|* the .port_name syntax. Similarly, A_pos, A_neg, A_signal_pos and
A_signal_neg pads are connected
|* through the [Series Pin Mapping] and [Diff Pin] keywords, respectively.
These names should not be used
|* as .port_names in ICM syntax, as these additional keywords and their pin
numbers alone are sufficient
|* to connect them.
|*
|* Digital ports cannot be connected to ICM packages.
|*
|* ICM may be used to define package models for IBIS [Component]s featuring a
mix of [Model] only and
|* [External Model] definitions. Care should be taken to avoid naming
conflicts in such cases.
|*
|* Connections Using [External Circuit]
|*
|* ICM may be used to define package behavioral information for connections
between
|* [External Circuit]s and [Pin]s, through the [Node Declarations] and [Circuit
Call] keywords. In
|* such cases, the pin names in the first column under [ICM Pin Map] must match
|* names under the third column of the [Circuit Call] Port_map section and, as
appropriate, the
|* [Node Declarations] keyword. No additional restrictions are placed, for
links to IBIS, on the
|* string argument to [ICM Pin Map] or Pin_order. The associated [ICM Pin Map]
may be row- or
|* column-ordered. Pin descriptions (the second column under [ICM Pin Map]) do
not have any special
|* meaning for connections to IBIS files.
|*
|* Therefore, the naming scheme in [ICM Pin Map]s to be used in connecting to
IBIS is:
|*
|* a) The [ICM Pin Map] for the component side connecting to the external world
uses IBIS [Pin]
|* names under the first (Pin) column
|* b) The [ICM Pin Map] for the die side of the component simply uses pad or
node names under the
|* first (Pin) column, as used under the [Circuit Call] and [Node
Declarations] keywords. Names
|* that match [Pin] strings are assumed to be implicit pad connections, not
IBIS [Pin] connections.
|*
|* Similarly, the naming scheme in [ICM Node Map]s to be used in connecting to
IBIS is:
|*
|* a) The [ICM Node Map] for the component side connecting to the external
world uses IBIS [Pin]
|* names under the first (Pin) column
|* b) The [ICM Node Map] for the die side of the component simply uses pad or
node names under the
|* first (Pin) column, as used under the [Circuit Call] and [Node
Declarations] keywords. Names
|* that match [Pin] strings are assumed to be implicit pad connections, not
IBIS [Pin] connections.
|*
|* As above, for both [ICM Node Map] and [ICM Pin Map], specific string
arguments must be used as names in order
|* to clearly identify the association between the IBIS and ICM nodes, pins
and/or pads.
|* The word "Die" must be used for the die pad side (buffer side) and "Pin" for
the pin/ball side (connected
|* outside of the component). The terms are case-sensitive.
|*
|* [Pin Mapping] is not supported in [Component]s featuring [External Circuit].
|* Therefore, power and ground supply nodes should be connected using ICM by
name
|* through [Node Declarations] and [Circuit Call], as detailed above.
|*
|* As with [External Model], under [External Circuit], digital ports cannot be
connected to ICM packages.
|*
|* No mixing of ICM-based and non-ICM [Package Model]s (e.g., .pkg format), is
permitted for the same
|* [Component[. An IBIS component may use either one or the other, but not
both. Package parameters
|* defined under [Pin] or [Package] may be used in the same [Component] as an
ICM-based [Package Model].
|* In this case, the [Pin] and/or [Package] information applies where no
ICM-based [Package Model]
|* information is provided; in cases where an ICM-based [Package Model] is
defined, the ICM data overrides
|* the [Pin] and [Package] data.
|*
|*****************************************************************************
|* END NEW TEXT
|*****************************************************************************
******************************************************************************
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION
[External Circuit] and associated keywords under IBIS 4.1 enable features
such as external controllability of buffer behaviors through feedback. To
make best use of these features in today's designs, package and on-die
interconnect models more complex than those supported by IBIS [Package
Model] were needed. Of greatest need was the ability to connect multiple
die pads to a single external pin.
At the time IBIS 4.1 was written, ICM was envisioned as the best method for
enabling these advanced features. ICM had not been completed before IBIS 4.1
was approved, so indirect references to ICM as a "non-native package model"
format were included in the 4.1 final document. The authors assumed that
tools could connect ICM and IBIS models at the user level, and that new
IBIS syntax to support ICM to IBIS connections would be easily added.
The IBIS 4.1 specification also allowed explicit pad definitions within
[Node Declarations] and Port_map.
IBIS 4.1 parser development exposed several critical barriers to linking
IBIS and ICM models. The main issues involve the IBIS assumption of a
"one-to-one" connection of die pads and pins, with the [Pin] keyword both
explicitly defining pins and implicitly defining die pads.
The changes above do not remove the 1-to-1 barrier for traditional IBIS.
Existing IBIS files constructed using IBIS 4.1 rules do not in any way change
in their interpretation with the introduction of explicit pad names.
Use of the [Package Model] and associated keywords ([Define Package Model],
etc.) is never required.
*****************************************************************************
ANY OTHER BACKGROUND INFORMATION:
From an informal suggestion by Arpad Muranyi, Intel Corp.
Several objectives helped define the structure of this BIRD:
- minimal changes to IBIS syntax
- minimal changes to ICM syntax
- continued support of [Pin Mapping] under traditional IBIS
- support for ICM under traditional IBIS, [External Model] and [External
Circuit]
- support for single-pad, multi-pin and single-pin, multi-pad packages (e.g.,
for stacked-die applications) through ICM
This last objective proved impossible to support using traditional IBIS
structures
and ICM without major changes to long-standing keywords such as [Pin]. This
BIRD therefore enables this last objective only for multi-lingual models.
The original IBIS specification text does not actually prohibit identical
pin identifiers (identical first column entries) under [Pin]. This could cause
shorting issues unless an additional rule is created to handle it.
Note that [Pin], [Package] and [Package Model] interactions with IBIS 4.1
and 4.2 files are unaffected; the 1-1 assumption still applies in this case if
ICM is not used as the package model format, through implicit pins. Explicit
pin
connections are, however, impossible using traditional IBIS package structures
and
multi-lingual syntax.
An additional ICM requirement is defined here: in order to make IBIS and ICM
work
together, the names "Pin" and "Pad" must be used for the relevant [ICM Pin Map]
or
[ICM Node Map]. This ensures that EDA tools will properly associate the ICM
data endpoints in cases where node or pin names are identical.
[Alternate Package Models] is impacted by this BIRD, though no explicit changes
to the text of that keyword are necessary. That keyword supports use of
external
filenames as well as package model names internal to the calling IBIS file.
A summary chart of package and IBIS syntax combinations is included below.
IBIS and ICM Package Combination Decoder Ring
IBIS Type Package Type [Pin Mapping]? Comment
Traditional Traditional No Legal
Traditional Traditional Yes Legal
Traditional ICM No Legal - uses
pulldown_ref, etc. names
Traditional ICM Yes Legal - uses [Pin
Mapping] rail names
[External Model] Traditional No Legal - power supply
connections ambiguous
[External Model] Traditional Yes Legal - uses [Pin
Mapping] rail names
[External Model] ICM No Legal - uses [External
Model] port names
[External Model] ICM Yes Legal - uses [Pin
Mapping] rail names
[External Circuit] Traditional No Legal - some node
connections ambiguous
[External Circuit] Traditional Yes Illegal
[External Circuit] ICM No Legal - uses [Circuit
Call], [Node Declarations]
[External Circuit] ICM Yes Illegal
******************************************************************************
Other related posts:
- » [ibis-macro] IBIS-ICM interfacing BIRD draft...
