All,
I will not be at next week's Interconnect Meeting, so please respond if
any of the following is not clear.
The Terminal section of an Interconnect Model describes how the terminals
of a Interconnect Model subckt instance in a SPICE deck need to be
connected at a buffer terminal, die-pad interface or pin/board interface.
Package models on pin records and [Define Package Model] are between the
pins of the component and the I/O buffer in the silicon. The model
between the pins of the component and the I/O buffer in the silicon can
either be in a single Interconnect Model, or can be split into
Interconnect Models between the pins of the component and the die-pad
interface, and Interconnect Models between the die-pad interface and the
I/O buffers.
The sub-parameter Number_of_terminals tells how many SPICE nodes are
required on the instance.
The terminal lines that follow this keyword describe what SPICE node each
terminal should be connected to.
* The first field <Terminal_number> is a number between 1 and the
<Number_of_terminals> that describes the ordinal number of the Node in the
[Interconnect Model] subckt instance.
* The Nodes are on either I/O connections or on rail connections.
o I/O connections are to pins that have a Model_name that is not POWER,
GND or NC. Each I/O connection is specified using Pin_name.
* It is assumed that each Pin_name has only one die-pad and on I/O buffer
terminal.
o A rail connection is to a signal on a pin that has Model_name POWER or
GND. \
* Interconnect models for rail connections can either be made to a
specific pin, die-pad or I/O buffers, or can be made to all of the pins,
die-pads or I/O buffers that have connects to that rail signal_name, or
can be made to a subset of the pins, die-pads or I/O buffers that have the
same bus_label.
The second and third required fields of the terminal record are the
<terminal_type> and < Terminal_type_qualifier >.
* For I/O terminals
o The <terminal_type> determines if the terminal is at the Buffer,
Die-Pad or Pin
o The < Terminal_type_qualifier > must be a Pin_name.
* For rail terminals
o At the Pin/Board interface
* Pin_name
* Signal_name
* Bus_label subset of a Signal_name
o At the Die-Pad interface
* Die_pad_name
* Signal_name
* Bus_label subset of a Signal_name
o At the buffer
* Pin_name
* A specific rail (e.g. Power_clamp_ref)
* Signal_name
* Bus_label subset of a Signal_name
Crosstalk simulations require Interconnect Models have connections to
multiple I/O Pin_names.
* It is often impractical to make Interconnect Models that include
all of the I/O connections in a component.
* A DQ bus on a memory controller can easily contain 128 pins, and
a fully coupled s-parameter would have 256 ports.
* An example is a model with the interconnect of DQ6, DQ7 and DQ8.
o DQ7 has crosstalk in the package with the adjoining signals DQ6 and
DQ8.
* This model represents all of the crosstalk on DQ7 (since it includes
DQ6 and DQ8).
o This model does not include all of the crosstalk affecting DQ8 since
the model does not include DQ9.
o Similarly DQ6 does not include all of its aggressors (DQ5).
o The model maker tells the EDA tool that connections to terminals DQ6
and DQ8 do not include all of their aggressors by adding the optional
field "Aggressor" to their terminals.
o In this case, simulations will include crosstalk on DQ6 and DQ8 from
DQ7, but it will not include crosstalk from their aggressors (DQ5 and
DQ9).
o The DQ7 connections do not have the optional "Aggressor" field. The
EDA tool may assume that DQ7 has all (or more practically most of) the
coupling to its aggressor connections.
Walter
Walter Katz
<mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 303.335-6156
