Note that the version below assumes that R_pin, etc. and the parameters under the [Package] keyword can be used with the new instance_name syntax. This is consistent with IBIS 4.1's multi-lingual features, which are strongly implied to work with normal package descriptions if a 1-to-1 relationship between pad and pin is assumed. I am willing to consider making them incompatible, but this carries large implications for how the R_pin and [Package] keyword parameters are interpreted today. ****************************************************************************** ****************************************************************************** BIRD ID#: 100 ISSUE TITLE: Package Model Enhancements; Linking ICM and IBIS REQUESTER: Michael Mirmak, Intel Corp. DATE SUBMITTED: July 27, 2005 DATE REVISED: DATE ACCEPTED BY IBIS OPEN FORUM: PENDING ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: The IBIS specification, versions 1.1 through 4.1, 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. This native format assumes that the [Pin] keyword describes and assigns 1-to-1 connections between buffers 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 "native" IBIS files to define multiple package connections to a single pin and/or a single buffer. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: All changes, with the exception of spacing and line break adjustments, are shown with |*. |***************************************************************************** |* ORIGINAL [PIN] TEXT |***************************************************************************** |============================================================================= | Keyword: [Pin] | Required: Yes | Description: Associates the component's I/O models to its various external | pin names and signal names. | Sub-Params: signal_name, model_name, R_pin, L_pin, C_pin | Usage Rules: All pins on a component must be specified. The first column | must contain the pin name. The second column, signal_name, | gives the data book name for the signal on that pin. The | third column, model_name, maps a pin to a specific I/O buffer | model or model selector name. Each model_name must have a | corresponding model or model selector name listed in a [Model] | or [Model Selector] keyword below, unless it is a reserved | model name (POWER, GND, or NC). | | The model_name column cannot be used for model or model | selector names that reference Series and Series_switch models. | | Each line must contain either three or six columns. A pin | line with three columns only associates the pin's signal and | model. Six columns can be used to override the default | package values (specified under [Package]) FOR THAT PIN ONLY. | When using six columns, the headers R_pin, L_pin, and C_pin | must be listed. If "NA" is in columns 4 through 6, the | default packaging values must be used. The headers R_pin, | L_pin, and C_pin may be listed in any order. | | Column length limits are: | [Pin] 5 characters max | model_name 20 characters max | signal_name 20 characters max | R_pin 9 characters max | L_pin 9 characters max | C_pin 9 characters max |----------------------------------------------------------------------------- [Pin] signal_name model_name R_pin L_pin C_pin | 1 RAS0# Buffer1 200.0m 5.0nH 2.0pF 2 RAS1# Buffer2 209.0m NA 2.5pF 3 EN1# Input1 NA 6.3nH NA 4 A0 3-state 5 D0 I/O1 6 RD# Input2 310.0m 3.0nH 2.0pF 7 WR# Input2 8 A1 I/O2 9 D1 I/O2 10 GND GND 297.0m 6.7nH 3.4pF 11 RDY# Input2 12 GND GND 270.0m 5.3nH 4.0pF | . | . | . 18 Vcc3 POWER 19 NC NC 20 Vcc5 POWER 226.0m NA 1.0pF 21 BAD1 Series_switch1 | Illegal assignment 22 BAD2 Series_selector1 | Illegal assignment | |***************************************************************************** |* 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 [NODE DECLARATIONS] TEXT |***************************************************************************** |============================================================================= | Keywords: [Node Declarations], [End Node Declarations] | Required: Yes, if any internal nodes exist on the die as listed in | [Circuit Call], and/or if any die pads need to be explicitly | defined. | Description: Provides a list of internal die nodes and/or die pads for a | [Component] to make unambiguous interconnection descriptions | possible. | Usage Rules: All die node and die pad names that appear under any [Circuit | Call] keyword within the same [Component] must be listed under | the [Node Declarations] keyword. | | If used, the [Node Declarations] keyword must appear before | any [Circuit Call] keyword(s) under the [Component] keyword. | Only one [Node Declarations] keyword is permitted for each | [Component] keyword. Since the [Node Declarations] keyword | is part of the [Component] keyword, all internal node or pad | references apply only to that [Component] (i.e., they are | local). | | The internal die node and/or die pad names within [Node | Declarations] must be unique and therefore different from | the pin names used in the [Pin] keyword. Each node and/or | pad name must be separated by at least one white space. The | list may span several lines and is terminated by the [End | Node Declarations] keyword. | | The names of die nodes and die pads can be composed of any | combination of the legal characters outlined in Section 3. |----------------------------------------------------------------------------- [Node Declarations] | Must appear before any [Circuit Call] keyword | | Die nodes: a b c d e | List of die nodes f g h nd1 | | Die pads: pad_2a pad_2b pad_4 pad_11 | List of die pads | [End Node Declarations] | |***************************************************************************** |* 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: |----------------------------------------------------------------------------- | | For the examples below please refer to the following | 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. | 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] 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] | |***************************************************************************** |* ORIGINAL PACKAGE FORMAT TEXT |***************************************************************************** |============================================================================= | Keyword: [Number Of Sections] | Required: No | Description: Defines the maximum number of sections that make up a 'package | stub'. A package stub is defined as the connection between | the die pad and the corresponding package pin; it can include | (but is not limited to) the bondwire, the connection between | the bondwire and pin, and the pin itself. This keyword must | be used if a modeler wishes to describe any package stub as | other than a single, lumped L/R/C. The sections of a package | stub are assumed to connect to each other in a series fashion. | Usage Rules: The argument is a positive integer greater than zero. This | keyword, if used, must appear in the specification before the | [Pin Numbers] keyword. The maximum number of sections | includes sections between the Fork and Endfork subparameters. |----------------------------------------------------------------------------- [Number Of Sections] 3 | |============================================================================= | Keyword: [Number Of Pins] | Required: Yes | Description: Tells the parser how many pins to expect. | Usage Rules: The field must be a positive decimal integer. The [Number | Of Pins] keyword must be positioned before the [Pin Numbers] | keyword. |----------------------------------------------------------------------------- [Number Of Pins] 128 | |============================================================================= | Keyword: [Pin Numbers] | Required: Yes | Description: Tells the parser the set of names that are used for the | package pins and also defines pin ordering. If the [Number Of | Sections] keyword is present it also lists the elements for | each section of a pin's die to pin connection. | Sub-Params: Len, L, R, C, Fork, Endfork | Usage Rules: Following the [Pin Numbers] keyword, the names of the pins are | listed. There must be as many names listed as there are pins | (as given by the preceding [Number Of Pins] keyword). Pin | names can not exceed 5 characters in length. The first pin | name given is the "lowest" pin, and the last pin given is the | "highest." If the [Number Of Sections] keyword is used then | each pin name must be followed by one or more of the legal | subparameter combinations listed below. If the [Number Of | Sections] keyword is not present then subparameter usage is | NOT allowed. | | Subparameters: | | The Len, L, R, and C subparameters specify the length, | inductance, capacitance and resistance of each section of each | stub on a package. | | The Fork and Endfork subparameters are used to denote branches | from the main package stub. | | Len The length of a package stub section. Lengths are | given in terms of arbitrary 'units'. | L The inductance of a package stub section, in terms of | 'inductance/unit length'. For example, if the total | inductance of a section is 3.0nH and the length of the | section is 2 'units', the inductance would be listed | as L = 1.5nH (i.e. 3.0 / 2). | C The capacitance of a package stub section, in terms of | capacitance per unit length. | R The DC (ohmic) resistance of a package stub section, | in terms of ohms per unit length. | Fork This subparameter indicates that the sections | following (up to the Endfork subparameter) are part of | a branch off of the main package stub. This | subparameter has no arguments. | Endfork This subparameter indicates the end point of a branch. | For every Fork subparameter there must be a | corresponding Endfork subparameter. As with the Fork | subparameter, the Endfork subparameter has no | arguments. | | Specifying a Len or L/R/C value of zero is allowed. If | Len = 0 is specified, then the L/R/C values are the total for | that section. If a non-zero length is specified, then the | total L/R/C for a section is calculated by multiplying the | value of the Len subparameter by the value of the L, R, or C | subparameter. However, if a non-zero length section is | specified, the L and C for that section should be treated as | distributed elements. | | Using The Subparameters to Describe Package Stub Sections: | | A section description begins with the Len subparameter and | ends with the slash (/) character. The value of the Len, L, | R, and C subparameters and the subparameter itself are | separated by an equals sign (=); white space around the equals | sign is optional. The Fork and Endfork subparameters are | placed between section descriptions (i.e., between the | concluding slash of one section and the 'Len' parameter that | starts another). A particular section description can contain | no data (i.e., the description is given as 'Len = 0 /'). | | Legal Subparameter Combinations for Section Descriptions: | | A) A single Len = 0 subparameter, followed by a slash. This | is used to describe a section with no data. | | B) Len, and one or more of the L, R and C subparameters. If | the Len subparameter is given as zero, then the L/R/C | subparameters represent lumped elements. If the Len | subparameter is non-zero, then the L/R/C subparameters | represent distributed elements. | | C) Single Fork or Endfork subparameter. Normally, a package | stub is described as several sections, with the Fork and | Endfork subparameters surrounding a group of sections in the | middle of the complete package stub description. However, it | is legal for the Fork/Endfork subparameters to appear at the | end of a section description. The package pin is connected to | the last section of a package stub description not surrounded | by a Fork/Endfork statements. See the examples below. | | Package Stub Boundaries: | | A package stub description starts at the connection to the die | and ends at the point at which the package pin interfaces with | the board or substrate the IC package is mounted on. Note | that in the case of a component with through-hole pins, the | package stub description should include only the portion of | the pin not physically inserted into the board or socket. | However, it is legal for a package stub description to include | both the component and socket together if this is how the | component is intended to be used. |---------------------------------------------------------------------------- | A three-section package stub description that includes a bond wire (lumped | inductance), a trace (treated as a transmission line with DC resistance), | and a pin modeled as a lumped L/C element. | [Pin Numbers] A1 Len=0 L=1.2n/ Len=1.2 L=2.0n C=0.5p R=0.05/ Len=0 L=2.0n C=1.0p/ | | Pin A2 below has a section with no data | A2 Len=0 L=1.2n/ Len=0/ Len=1.2 L=2.0n C=0.5p R=0.05/ Len=0 L=2.0n C=1.0p/ | | A section description using the Fork and Endfork subparameters. Note that | the indentation of the Fork and Endfork subparameters are for readability | are not required. | A1 Len=0 L=2.3n / | bondwire Len=1.2 L=1.0n C=2.5p / | first section Fork | indicates the starting of a branch Len=1.0 L=2.0n C=1.5p / | section Endfork | ending of the branch Len=0.5 L=1.0 C=2.5p/ | second section Len=0.0 L=1.5n / | pin | | Here is an example where the Fork/Endfork subparameters are at the end of a | package stub description. | B13 Len=0 L=2.3n / | bondwire Len=1.2 L=1.0n C=2.5p / | first section Len=0.5 L=1.0 C=2.5/ | second section, pin connects here Fork | indicates the starting of a branch Len=1.0 L=2.0n C=1.5p / | section Endfork | ending of the branch | |============================================================================= | Keywords: [Resistance Matrix], [Inductance Matrix], [Capacitance Matrix] | Required: [Resistance Matrix] is optional. If it is not present, its | entries are assumed to be zero. [Inductance Matrix] and | [Capacitance Matrix] are required. | Sub-Params: Banded_matrix, Sparse_matrix, or Full_matrix | Description: The subparameters mark the beginning of a matrix, and specify | how the matrix data is formatted. | Usage Rules: For each matrix keyword, use only one of the subparameters. | After each of these subparameters, insert the matrix data in | the appropriate format. (These formats are described in | detail below.) | Other Notes: The resistance, inductance, and capacitance matrices are also | referred to as "RLC matrices" within this specification. | | When measuring the entries of the RLC matrices, either with | laboratory equipment or field-solver software, currents are | defined as ENTERING the pins of the package from the board | (General Syntax Rule #11). The corresponding voltage drops | are to be measured with the current pointing "in" to the "+" | sign and "out" of the "-" sign. | | I1 +-----+ I2 | -----> | | <------ | board o--------| Pkg |---------o board | + V1 - | | - V2 + | +-----+ | | It is important to observe this convention in order to get the | correct signs for the mutual inductances and resistances. |----------------------------------------------------------------------------- [Resistance Matrix] Banded_matrix [Inductance Matrix] Sparse_matrix [Capacitance Matrix] Full_matrix |***************************************************************************** |* END ORIGINAL TEXT |***************************************************************************** |***************************************************************************** |* NEW [PIN] TEXT BELOW |***************************************************************************** |============================================================================= | Keyword: [Pin] | Required: Yes | Description: Associates the component's I/O models to its various external | pin names and signal names. |* Sub-Params: signal_name, model_name, R_pin, L_pin, C_pin, instance_name | Usage Rules: All pins on a component must be specified. The first column | must contain the pin name. The second column, signal_name, | gives the data book name for the signal on that pin. The | third column, model_name, maps a pin to a specific I/O buffer |* model instance_name or [Model Selector] name. Each |* model_name must have a corresponding model or model selector |* name listed in a [Model] or [Model Selector] keyword below, |* unless it is a reserved model name (POWER, GND, CIRCUITCALL |* or NC). | |* The optional column instance_name provides a unique name for |* the specific instance of the buffer [Model] named by the |* entry in the model_name column. |* |* If instance_name is not used under a particular [Component]'s |* [Pin] listing, each entry under the first column of [Pin] |* must be unique. Entries under the first three columns of |* [Pin] may be repeated if the repeated entries use the |* instance_name column and follow associated instance_name |* rules. | | The model_name column cannot be used for model or model | selector names that reference Series and Series_switch models. | |* Each [Pin] entry defines a physical pin on the component, |* the pin's name and an associated instance of the named |* [Model]. In the absence of an instance_name entry for a pin, |* that pin is assumed to connect only to one instance of the |* named [Model], through a package interconnect defined through |* the R_pin, L_pin and C_pin entries, the contents of the |* [Package] keyword or the contents of an associated |* [Package Model]. | |* Each line must contain either three, six or seven columns. A |* pin line with only three columns associates the pin's signal |* name and model. Six columns can be used to override the default | package values (specified under [Package]) FOR THAT PIN ONLY. | When using six columns, the headers R_pin, L_pin, and C_pin |* must be listed. If "NA" is used in columns 4 through 6 for |* a particular [Pin] entry, the package information under |* the [Package] keyword is assumed. The headers R_pin, | L_pin, and C_pin may be listed in any order. | |* When using seven columns, the instance_name header must be |* listed. If instance_name is used, the R_pin, L_pin and C_pin |* columns MUST contain entries, though these entries may be NA. |* |* Use of instance_name permits multiple buffers described by |* the same [Model] to connect to the same pin. Additionally, |* instance_name enables multiple pins to connect to the same |* physical buffer. Note that instance_name instantiates a |* buffer's die pad, for purposes of connecting package |* interconnect. Data for R_pin, L_pin and C_pin subparameters |* and the [Package] are assumed associated with pins, not buffer |* pads. Therefore, in the case where multiple buffers connect |* to the same pin through instance_name, the buffers are assumed |* short-circuited at the buffer pad, with ONE package |* interconnect path between pad and pin. Similarly, if a single |* buffer connects to multiple pins through instance_name, the |* R_pin, etc. and [Package] data describe the package |* interconnect connected to each pin -- separate package paths |* per pin -- but shorted together at the pad. |* |* Note that instance_name does NOT enable the creation of |* multiple buffers using different [Model] descriptions which |* share a pad. Connecting between pads of different [Model]s |* must be achieved through [Package Model] or [External Circuit]. |* |* Note that the values of the entries under R_pin, L_pin and |* C_pin will be ignored for [Pin]s containing instance_name |* entries. Similarly, [Package] keyword entries are ignored |* for any [Pin] which features an instance_name entry In |* these cases, package data must be defined through the |* [Package Model] keyword. |* |* Each repeated entry under the first column of [Pin] must have |* the same signal_name as all other pins using the same column |* 1 entry (see examples below). Any [Pin] which uses the same |* column 1 entry as another pin MUST have an instance_name |* entry as well, even if the model_name is different. |* |* No entry in the instance_name field is permitted for [Pin]s |* of type NC or CIRCUITCALL. |* |* Identical entries under instance_name must NEVER be used for |* different buffer instances, regardless of whether dissimilar |* buffer types, [Model]s or [Pin]s are used. While not |* strictly necessary for logical parsing, this prevents |* confusion by model authors and EDA tool writers. |* |* [Pin] entries which use the instance_name column MUST also |* use the "Pad" subparameter under [Pin Numbers], if the IBIS |* package model format is used. |* |* The instance_name subparameter MUST be used for all [Pin] |* entries if an ICM file is used to model package interconnect. | | Column length limits are: |* [Pin] 15 characters max | model_name 20 characters max | signal_name 20 characters max | R_pin 9 characters max | L_pin 9 characters max | C_pin 9 characters max |* instance_name 20 characters max |----------------------------------------------------------------------------- |* [Pin] signal_name model_name R_pin L_pin C_pin instance_name | 1 RAS0# Buffer1 200.0m 5.0nH 2.0pF 2 RAS1# Buffer2 209.0m NA 2.5pF 3 EN1# Input1 NA 6.3nH NA 4 A0 3-state 5 D0 I/O1 6 RD# Input2 310.0m 3.0nH 2.0pF 7 WR# Input2 8 A1 I/O2 9 D1 I/O2 10 GND GND 297.0m 6.7nH 3.4pF 11 RDY# Input2 12 GND GND 270.0m 5.3nH 4.0pF |* 13 CLK Input3 NA NA NA InBuf1 |* 13 CLK Input3 NA NA NA InBuf2 |* |* Pin 13 above is named CLK and is tied to TWO independent buffers, with the |* same model_name. One buffer instance is called InBuf1 and the other is |* called InBuf2. Both refer to the same [Model] definition, Input3. |* |* 14 CONTROL Input4 NA NA NA InControl |* 14 CONTROL Output1 NA NA NA OutControl |* |* Pin 14 above is named CONTROL and is intended for use as feedback buffer |* control. This pin is tied to TWO independent buffers. The buffers use |* [Model] definitions Input4 and Output1 in the IBIS file and are named |* InputControl and OutputControl, respectively. |* |* 15 D3 Output2 NA NA NA OutBufA |* 16 D4 Output2 NA NA NA OutBufA |* |* Pins 15 and 16 above are named D3 and D4, respectively. These |* pins are tied to the same instance, named OutBufA, of the [Model] |* definition Output2 later in the IBIS file. | . | . | . 18 Vcc3 POWER 19 NC NC 20 Vcc5 POWER 226.0m NA 1.0pF 21 BAD1 Series_switch1 | Illegal assignment 22 BAD2 Series_selector1 | Illegal assignment | |============================================================================= | 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 [NODE DECLARATIONS] TEXT |***************************************************************************** |============================================================================= | Keywords: [Node Declarations], [End Node Declarations] | Required: Yes, if any internal nodes exist on the die as listed in | [Circuit Call], and/or if any die pads need to be explicitly | defined. | Description: Provides a list of internal die nodes and/or die pads for a | [Component] to make unambiguous interconnection descriptions | possible. | Usage Rules: All die node and die pad names that appear under any [Circuit | Call] keyword within the same [Component] must be listed under | the [Node Declarations] keyword. | | If used, the [Node Declarations] keyword must appear before | any [Circuit Call] keyword(s) under the [Component] keyword. | Only one [Node Declarations] keyword is permitted for each | [Component] keyword. Since the [Node Declarations] keyword | is part of the [Component] keyword, all internal node or pad | references apply only to that [Component] (i.e., they are | local). | | The internal die node and/or die pad names within [Node | Declarations] must be unique and therefore different from | the pin names used in the [Pin] keyword. Each node and/or | pad name must be separated by at least one white space. The | list may span several lines and is terminated by the [End | Node Declarations] keyword. | | The names of die nodes and die pads can be composed of any | combination of the legal characters outlined in Section 3. |----------------------------------------------------------------------------- [Node Declarations] | Must appear before any [Circuit Call] keyword | | Die nodes: a b c d e | List of die nodes f g h nd1 | | Die pads: pad_2a pad_2b pad_4 pad_11 | List of die pads | [End Node Declarations] | New text, under [Circuit Call] keyword definition: | 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). |* |* When a [Pin] list uses an explicit buffer name through the |* instance_name field, the second argument of Port_map must |* match the instance_name used for the corresponding pin in |* the [Pin] list. |* |----------------------------------------------------------------------------- | Examples: |----------------------------------------------------------------------------- | | For the examples below please refer to the following | 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. | 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] 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] | |***************************************************************************** |* NEW PACKAGE FORMAT TEXT BELOW |***************************************************************************** | |============================================================================= | Keyword: [Number Of Sections] | Required: No | Description: Defines the maximum number of sections that make up a 'package | stub'. A package stub is defined as the connection between |* a die pad and a package pin; it can include (but is not |* limited to) a bondwire, the connection between | the bondwire and pin, and the pin itself. This keyword must | be used if a modeler wishes to describe any package stub as | other than a single, lumped L/R/C. The sections of a package | stub are assumed to connect to each other in a series fashion. | Usage Rules: The argument is a positive integer greater than zero. This | keyword, if used, must appear in the specification before the | [Pin Numbers] keyword. The maximum number of sections | includes sections between the Fork and Endfork subparameters. |----------------------------------------------------------------------------- [Number Of Sections] 3 | |============================================================================= | Keyword: [Number Of Pins] | Required: Yes |* Description: Tells the parser how many unique pins to expect. | Usage Rules: The field must be a positive decimal integer. The [Number | Of Pins] keyword must be positioned before the [Pin Numbers] |* keyword. Note that repeated pins in a [Pin] list featuring |* instance_name should only be counted once. |----------------------------------------------------------------------------- [Number Of Pins] 128 | |============================================================================= | Keyword: [Pin Numbers] | Required: Yes | Description: Tells the parser the set of names that are used for the | package pins and also defines pin ordering. If the [Number Of | Sections] keyword is present it also lists the elements for | each section of a pin's die to pin connection. |* Sub-Params: Pad, Len, L, R, C, Fork, Endfork | Usage Rules: Following the [Pin Numbers] keyword, the names of the pins |* are listed. There must be, at a minimum, as many names |* listed as there are pins (as given by the preceding |* [Number Of Pins] keyword). Pin names may be duplicated and |* package paths between identical endpoints (buffer and pin) |* will be considered as routed in parallel. |* |* Pin names can not exceed 15 characters in length. The first pin | name given is the "lowest" pin, and the last pin given is the | "highest." If the [Number Of Sections] keyword is used then | each pin name must be followed by one or more of the legal | subparameter combinations listed below. If the [Number Of | Sections] keyword is not present then subparameter usage is | NOT allowed. | | Subparameters: | | The Len, L, R, and C subparameters specify the length, | inductance, capacitance and resistance of each section of each | stub on a package. |* |* The optional Pad subparameter specifies the pad of the |* connected buffer, using the instance_name of the buffer |* connected to the package stub, in cases where more than one |* buffer may be connected to the same pin, or more than one pin |* may be connected to the same buffer. | | The Fork and Endfork subparameters are used to denote branches | from the main package stub. | | Len The length of a package stub section. Lengths are | given in terms of arbitrary 'units'. | L The inductance of a package stub section, in terms of | 'inductance/unit length'. For example, if the total | inductance of a section is 3.0nH and the length of the | section is 2 'units', the inductance would be listed | as L = 1.5nH (i.e. 3.0 / 2). | C The capacitance of a package stub section, in terms of | capacitance per unit length. | R The DC (ohmic) resistance of a package stub section, | in terms of ohms per unit length. |* Pad The die pad of the buffer, named after the buffer |* instance. This must match one of the "instance_name" |* entries given for this pin under the [Pin] keyword. |* This subparameter is required if instance_name is |* used for the particular [Pin] of interest. | Fork This subparameter indicates that the sections | following (up to the Endfork subparameter) are part of | a branch off of the main package stub. This | subparameter has no arguments. | Endfork This subparameter indicates the end point of a branch. | For every Fork subparameter there must be a | corresponding Endfork subparameter. As with the Fork | subparameter, the Endfork subparameter has no | arguments. | | Specifying a Len or L/R/C value of zero is allowed. If | Len = 0 is specified, then the L/R/C values are the total for | that section. If a non-zero length is specified, then the | total L/R/C for a section is calculated by multiplying the | value of the Len subparameter by the value of the L, R, or C | subparameter. However, if a non-zero length section is | specified, the L and C for that section should be treated as | distributed elements. | | Using The Subparameters to Describe Package Stub Sections: | |* A section description begins with the Len or Pad |* subparameters and ends with the slash (/) character. The |* argument of the Buffer, Len, L, R, and C subparameters and |* the subparameter itself are separated by an equals sign (=); |* white space around the equals sign is optional. The Fork |* and Endfork subparameters are placed between section |* descriptions (i.e., between the concluding slash of one |* section and the 'Len' parameter that starts another). A |* particular section description can contain no data (i.e., |* the description is given as 'Len = 0 /'). | |* The Pad subparameter is placed at the location in the path |* where the buffer is physically connected, either between the |* first instance of Len and the pin name or before an Endfork |* subparameter. In cases where the Pad subparameter is |* entirely omitted, the package path is assumed to connect the |* named pin to a single instance of the model listed for the |* corresponding pin name under [Pin]. | | Legal Subparameter Combinations for Section Descriptions: | | A) A single Len = 0 subparameter, followed by a slash. This | is used to describe a section with no data. | | B) Len, and one or more of the L, R and C subparameters. If | the Len subparameter is given as zero, then the L/R/C | subparameters represent lumped elements. If the Len | subparameter is non-zero, then the L/R/C subparameters | represent distributed elements. | | C) Single Fork or Endfork subparameter. Normally, a package | stub is described as several sections, with the Fork and | Endfork subparameters surrounding a group of sections in the | middle of the complete package stub description. However, it | is legal for the Fork/Endfork subparameters to appear at the | end of a section description. The package pin is connected to | the last section of a package stub description not surrounded | by a Fork/Endfork statements. See the examples below. |* |* D) Pad, a single Len = 0 subparameter, followed by a slash. |* This is used to describe a section with no data. |* |* E) Pad, Len, and one or more of the L, R and C subparameters. |* The Len subparameter follows the rules given above. |* |* F) Single Pad subparameter. A Pad subparameter indicates |* a connection to a buffer model die pad. This may occur inside a |* Fork/Endfork pair; if the buffer is the endpoint, the Pad |* subparameter will be placed just before Endfork. Pad may also be |* used to signify an "in-line" or nodal connection to the package |* path. | | | Package Stub Boundaries: | | A package stub description starts at the connection to the die | and ends at the point at which the package pin interfaces with | the board or substrate the IC package is mounted on. Note | that in the case of a component with through-hole pins, the | package stub description should include only the portion of | the pin not physically inserted into the board or socket. | However, it is legal for a package stub description to include | both the component and socket together if this is how the | component is intended to be used. |---------------------------------------------------------------------------- | A three-section package stub description that includes a bond wire (lumped | inductance), a trace (treated as a transmission line with DC resistance), | and a pin modeled as a lumped L/C element. | [Pin Numbers] A1 Len=0 L=1.2n/ Len=1.2 L=2.0n C=0.5p R=0.05/ Len=0 L=2.0n C=1.0p/ | | Pin A2 below has a section with no data | A2 Len=0 L=1.2n/ Len=0/ Len=1.2 L=2.0n C=0.5p R=0.05/ Len=0 L=2.0n C=1.0p/ | | A section description using the Fork and Endfork subparameters. Note that | the indentation of the Fork and Endfork subparameters are for readability | are not required. | A1 Len=0 L=2.3n / | bondwire Len=1.2 L=1.0n C=2.5p / | first section Fork | indicates the starting of a branch Len=1.0 L=2.0n C=1.5p / | section Endfork | ending of the branch Len=0.5 L=1.0 C=2.5p/ | second section Len=0.0 L=1.5n / | pin | | Here is an example where the Fork/Endfork subparameters are at the end of a | package stub description. | B13 Len=0 L=2.3n / | bondwire Len=1.2 L=1.0n C=2.5p / | first section Len=0.5 L=1.0 C=2.5/ | second section, pin connects here Fork | indicates the starting of a branch Len=1.0 L=2.0n C=1.5p / | section Endfork | ending of the branch | |* Here is an example where a buffer pad is explicitly linked to the named pin. |* |* C2 Pad=OutBufA Len=0 L=2.3n / | Buffer pad and bondwire |* Len=1.2 L=1.0n C=2.5p / | first section |* Len=0.5 L=1.0 C=2.5/ | second section, pin connects here |* Fork | indicates the starting of a branch |* Len=1.0 L=2.0n C=1.5p / | section |* Endfork | ending of the branch |* The connection to the named pin follows the final Endfork |* |* Here is an example where a two Buffers are explicitly linked to the |* same named pin. |* |* 14 Buffer=InControl Len=0 L=2.3n / | Buffer and bondwire |* Fork | indicates the starting of a branch |* Len=0 L=2.3n / | a different bondwire |* Pad=OutControl | Buffer pad |* Endfork | ending of the branch |* Len=1.2 L=1.0n C=2.5p / | first section |* Len=0.5 L=1.0 C=2.5/ | second section, pin connects here |* Fork | indicates the starting of a branch |* Len=1.0 L=2.0n C=1.5p / | section |* Endfork | ending of the branch |* The connection to the named pin follows the final Endfork |* |* |* The example lines below show different buffer pads connected to the same pin |* by duplicating the same pin name. |* |* A2 Pad=OutControl Len=0 L=1.2n/ Len=0/ Len=1.2 L=0 C=0.5p R=0.5/ Len=0 L=2.0n/ |* A2 Pad=InControl Len=0 L=1.2n/ Len=0/ Len=1.2 L=0 C=0.5p R=0.5/ Len=0 L=2.0n/ |============================================================================= | Keywords: [Resistance Matrix], [Inductance Matrix], [Capacitance Matrix] | Required: [Resistance Matrix] is optional. If it is not present, its | entries are assumed to be zero. [Inductance Matrix] and | [Capacitance Matrix] are required. | Sub-Params: Banded_matrix, Sparse_matrix, or Full_matrix | Description: The subparameters mark the beginning of a matrix, and specify | how the matrix data is formatted. | Usage Rules: For each matrix keyword, use only one of the subparameters. | After each of these subparameters, insert the matrix data in | the appropriate format. (These formats are described in | detail below.) | Other Notes: The resistance, inductance, and capacitance matrices are also | referred to as "RLC matrices" within this specification. | | When measuring the entries of the RLC matrices, either with | laboratory equipment or field-solver software, currents are | defined as ENTERING the pins of the package from the board | (General Syntax Rule #11). The corresponding voltage drops | are to be measured with the current pointing "in" to the "+" | sign and "out" of the "-" sign. | | I1 +-----+ I2 | -----> | | <------ | board o--------| Pkg |---------o board | + V1 - | | - V2 + | +-----+ | | It is important to observe this convention in order to get the | correct signs for the mutual inductances and resistances. |* |* Note that the matrix format of package information cannot |* be used to represent packages where the number of pins and |* the number of buffers are not equal (in other words, if the |* instance_name field under [Pin] has been used to associate |* multiple buffers with a single pin or multiple pins with a |* single buffer. |----------------------------------------------------------------------------- [Resistance Matrix] Banded_matrix [Inductance Matrix] Sparse_matrix [Capacitance Matrix] Full_matrix |*============================================================================= |* NOTES ON CONNECTING IBIS AND ICM MODELS |* IBIS Interconnect Modeling (ICM) Specification Models may be used as package |* models, if they 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.0 of the ICM |* Specification for details on the ICM keywords mentioned below. |* |* Connections between pins named under the IBIS [Pin] keyword and the individual |* buffer pads used by instances of [Model] may be accomplished in two ways: |* |* a) implicitly, where a single buffer is assumed connected to the named pin |* without being named |* b) explicitly, where one or more buffers are named using the [Pin] |* subparameter instance_name. |* |* No distinction is made between the buffer and its die pad, in terms of |* naming. |* HEY - this will work ONLY if you don't care about the whole issue of power and ground mapping |* Connections are made using the [ICM Model Nodemap] keyword. A specific |* [ICM Model Nodemap] keyword section must be present and match the [Pin] |* list of the associated IBIS model by name. Similarly, a specific |* [ICM Model Nodemap] 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, in the case of implicit pads, or from the instance_name |* in the case of explicit pad names. |* |* 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 port_name of interest. |* |* Therefore, the referencing scheme to be used in connecting ICM models |* is: |* |* a) Pin_name for ICM Model Nodemap on the pin side |* b) Pin_name.port_name.instance_name for ICM Model Nodemap on the die side in cases of |* implicitly named buffers |* c) Pin_name.instance_name.port_name for die side in cases where the buffer |* is explicitly named through the instance_name subparameter under [Pin]. |* |* The Side subparameter must be used, and must use the words "Die" for the |* die side (buffer side) inand "Pin" |* |* [ICM Model Nodemap] node names and signal names are not in any way determined |* by the IBIS model. |* |* No details regarding the interconnect between the pin and buffer or pad are |* included in an IBIS model which makes use of ICM. Therefore, all connectivity |* is specified in the associated ICM model, which will also contain references |* to the IBIS [Component], [Model], [Pin], analog ports (even for [Model]s not |* containing [External Model]) and, where appropriate, instance_name. |* |* Use of [Tree Path Description] for IBIS packages is not permitted. No mixing |* of ICM and native IBIS package formats is permitted; an IBIS model must either |* use one or the other, but not both. |* |***************************************************************************** |* 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 remove the 1-to-1 barrier, and permit explicit naming of buffer connections and instances, without forcing a complete rewrite of the [Pin] keyword. This change also enables the expansion of the single-line package model format used in IBIS and PKG files. Because of the structure of matrices in IBIS packages -- where each pin is assumed to have one and only one buffer attached -- the addition of explicit buffer names does not enable matrix data to be used to describe packages other than under the 1-to-1 assumption. 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. If instance_name and Buffer= notation is not used, a 1-to-1 mapping between pins and implied model instances (buffer die pads) is still assumed. Use of the [Package Model] and associated keywords ([Define Package Model], etc.) is never required. However, use of "instance_name" in the absence of package definitions can create situations where connections between buffers and pins are ambiguous. Tools may have difficulty performing signal integrity analyses without this information. As a side-effect, this BIRD also extends the permitted length of the [Pin] keyword's first column. ***************************************************************************** ANY OTHER BACKGROUND INFORMATION: From an informal suggestion by Arpad Muranyi, Intel Corp. The original IBIS specification text does not actually prohibit identical pin identifiers (identical first column entries) under [Pin]! ******************************************************************************