BIRD31 - CONNECTOR MODELS

To IBIS Members:

BIRD31 for Version 3.0 proposes a method for IBIS to model connectors in
multi-board simulation which leverages off of the existing package model
syntax and extensions.

Bob Ross,
Interconnectix, Inc.

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

BIRD ID#: 31
ISSUE TITLE: Connector Models
REQUESTER: Bob Ross, Interconnectix, Inc.
DATE SUBMITTED: 11/22/95
DATE ACCEPTED BY IBIS OPEN FORUM: Pending

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

STATEMENT OF THE ISSUE:

No guidance is given within IBIS with respect to modeling connectors and
their interconnection to other boards.

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

STATEMENT OF THE RESOLVED SPECIFICATIONS:

A CONNECTOR MODELING section following the PACKAGE MODELING section is added
to describe how connectors can be modeled. The proposed approach does not
contain any technical change or new keywords and sub-parameters.

|=============================================================================
|
| CONNECTOR MODELING
|
| This section describes how connectors can be modeled and how connection
| paths between boards are modeled.
|
| Each side of a connector may be configured as a complete IBIS [Component].
| This is illustrated using the default [Package] sub-parameters L_pkg, R_pkg,
| and C_pkg:
|
|
| L_pkg_1 R_pkg_1
| n1 o-----+---@@@@@---/\/\/\-------+
| | ___|___
| | NC, | |
| __|__ POWER or, | | Optional
| C_pkg_1 _____ GND or | | [Model]
| | |_______|
| | |
| GND GND, Gnd_Clamp Reference,
| or Power Clamp Reference
|
| Model of Board 1, Connector m1, Pin n1
|
|
| R_pkg_2 L_pkg_2
| +--------/\/\/\---@@@@@---+-----o n2
| ___|___ |
| NC, | | |
| POWER or, | | Optional __|__
| GND or | | [Model] _____ C_pkg_2
| |_______| |
| | |
| GND, Gnd_Clamp Reference, GND
| or Power Clamp Reference
|
| Model of Board 2, Connector m2, Pin n2
|
|
| When, pins n1 and n2 are connected (as specified by the simulator), they
| are joined at the die position of each model. This is illustrated below:
|
|
|
| Board 1, Connector m1 Board 2, Connector m2
|
| Connection
| L_pkg_1 R_pkg_1 V R_pkg_2 L_pkg_2
| n1 o-----+---@@@@@---/\/\/\-------+--------/\/\/\---@@@@@---+-----o n2
| | ___|___ |
| | NC, | | |
| __|__ POWER or, | | Optional __|__
| C_pkg_1 _____ GND or | | [Model](s) _____ C_pkg_2
| | |_______| |
| | | |
| GND GND, Gnd_Clamp Reference, GND
| or Power Clamp Reference
|
| Example of Model Showing Connection of Pins n1 and n2
|
|
| This illustration also applies to other package model forms by substituting
| The [Pin] sub-parameters L_pin, R_pin and C_pin or the [Define Package
| Model] matrix keywords [Inductance Matrix], [Resistance Matrix] and
| [Capacitance Matrix] for the L_pkg, R_pkg, and C_pkg elements above.
| Furthermore, the complete set of sections contained in a [Define Package
| Model] description could be substituted. So, discrete elements, transmission
| line elements and coupled matrix sections also can be used to model connector
| pins.
|
| The connector elements of each board do not have to be symmetrical, nor
| do they have to be of the same form. The connectivity model is just the
| cascading of separate models on each board. So, for example, Board 1 may
| be described by the default package parameters while board 2 may be described
| by with [Define Package Model] and several sections.
|
| NC, POWER, or GND can be used for the model_name definition so that the
| [Component] keyword for the connector conforms to IBIS syntax rules. An
| actual model_name with a corresponding [Model] keyword may be used. The
| most common application will be to insert a Terminator model to provide
| an additional C_comp element and possibly some built-in connector clamping
| and resistive elements.
|
| All other model types are permitted for active elements. However, unless
| there really is an active element within a connector, these models would
| normally be used as stubs for simulation purposes. No connection would
| be specified by the simulator.
|
| If no connection exists, as might occur when the board has an optional
| memory card, the complete [Component] model provides the termination
| of each pin. Since connector model data is most frequently given with
| the connector connected, this no-connect model may only serve as an
| approximation.
|
| If electrical model details of non-connect modes exist, they could by added
| by using [Model Selector] keyword selections.
|
|=============================================================================

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

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:

Connectors may appear as components just like any other electrical part.
Thus, they can be described by IBIS models. Thus electrical stubs can be
introduced for single board analysis. However, this approach may not be
sufficiently accurate.

Multi-board analysis is becoming a requirement and a reality. The proposal
gives a method of providing accurate models for the connector. The
connectivity itself must be described by the simulator.

Because the connector structures have similar characteristics as package
structures, the approach here is to leverage off of the exiting package
syntax and extensions. Thus, no new keywords or sub-parameters are needed.
Connector models are therefore handled in a totally consistent manner.

With the [Model Selector] extension, even connected and non-connected
modes of connectors can be modeled. This is a realistic situation with
optional memory cards and open backplane slots.

Possible extensions to include cables are not considered here. They could
be simulator specific and could be modeled as another type of "board"
in multi-board analysis.

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

ANY OTHER BACKGROUND INFORMATION:

Thanks to Chris Reid for suggesting this approach.

******************************************************************************
Received on Wed Nov 22 15:32:52 1995