Forwarded: Re: BIRD 31.1

I forgot to forward this to the ibis reflector.

Bob

Date: Wed, 3 Apr 96 19:18 PST
From: bob@icx.com ( Bob Ross)
To: hank.herrmann@amp.com
Subject: Re: BIRD 31.1

Hank and IBIS Committee:

Thank you for your thorough and thoughtful review. At some risk of confusing
the context, I have pulled out your concerns and deleted most of the
surrounding text. My responses are on lines without ">>". More discussion
is most welcome.

Bob Ross
Interconnectix, Inc.

> Wed, 3 Apr 1996 10:26:01 -0500
> From: Herrmann Hank <hank.herrmann@amp.com>
> To: IBIS Reflector <ibis@vhdl.org>
> Cc: Millard Steve <steve.millard@amp.com>,
> Schroeder Jim <jim.schroeder@amp.com>
> Subject: BIRD 31.1
> Date: Wed, 03 Apr 96 10:21:00 E

> I have attached the full text of BIRD 31.1 with my comments and questions
> inserted and marked off with ">>>" symbols so they are easy to find.

> Hank Herrmann
> Technical Staff Member
> AMP Incorporated, Electromagnetic Technology
> M.S. 106-14
> P.O. Box 3608
> Harrisburg, PA 17105-3608

> Phone: 717-986-5534
> FAX: 717-986-5643
> INTERNET: hank.herrmann@amp.com

> [[ Cmts_02_00.txt : 2654 in Cmts_02_.00t ]]

> 3/28/96

> Comments & Questions to BIRD 31.1 They are inserted in the text of the BIRD
> and are set off with ">>>>>>>>>>" symbols.

> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > General Questions & Comments:
> > 1. The Minimum Edge Rate for a package, connector or cable model should be
> > specified as a required parameter. A required Keyword, such as
> > [Minimum Edge Rate], should be added. Eventually, simulators should
> > generate a warning message if faster signals are impinging on the model.

1. If it is to be included, I would prefer it to be a required subparameter
    for Mated Models only. It would be a "specification" type subparameter
    such as Vinl and Vinh rather than a model element. In Spice models,
    such information exists only as a comment line. Since the [Description]
    keyword is required, I would prefer it to be captured there. However,
    the IBIS Committee can decide this.

> > 2. The word "STUB" is used to mean a conductive or transmission path
> > through a model. Is that normal EDA / IC / IBIS terminology? It
> > is confusing to connector modelers because a "STUB" to us is a passive
> > tap off of a transmission path. The word "PATH" would be preferred.

2. The STUB term is used in BIRD28.3. I believe it is correct in the
    context that it is used, but can understand the terminology confusion.
    Comments???

> > 3. How can connections be established between pins and internal matrix
> > tie points? Transmission and shielded type connectors require them.
> > Shielded cables, and transmission paths over ground planes can also
> > require them.

3. An extension can be a possible [Conductance] matrix or conductance element
    to complete the coupled RL/GC incremental model - within this proposal.
    The package subcommittee may propose some extensions. Otherwise such
    tie points would not be possible.

> > 4. Un-mated connector models are not the same as a mated model that is
> > not connected to something. Empty sockets and un-used bus slots
> > present a reduced capacitance and there may be no significant
> > inductance. There are also backplane connectors that have pin fields
> > that penetrate through the PCB and provide a 'back panel connection
> > point'. They too, are often not connected. A much more simple single
> > sided model would be the preferred structure for such device models.

4. This proposal does not cover un-mated models. However, it may be
    possible to use the existing [Component] description for the connector
    pins and populate them with NC, POWER, and GND pins as appropriate,
    and include with the [Package] or [Pin] models the un-mated description.
    So, when the connector is not connected, these parasitics would be
    used.

> > 5. This appears to describe an entire connector without the use of
> > reusable sub-matrixes. Is that correct? If so, is that really an
> > acceptable general solution?

5. This proposal will track any extension that is proposed by the package
    subcommittee with respect to reusable sub-matrices. So far, there is
    no approved format for this.

> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > Where are the boundaries for a Package model? Do they extend to the end of
> > the pins or SMT legs or do they stop short somewhere?
> > A standard boundary should be established. We use the plane at the top of
> > the socket. We find that necessary because of the interaction of the IC
> > pin with the Socket Contacts when C & L parameters are extracted. It is
> > also a reasonable boundary, from the IC perspective, since it coincides
> > with the plane of a PCB surface. The IC pins always go into a PCB or into
> > a socket below that boundary.
> > It is also important to define boundaries for the .mmf models.

  My understanding is that the Package model includes the printed circuit
  board pad (C_pad or C_pin). Since the Mated Model would not exist within
  a .ibs file, its boundaries stop at the plane at the top of the socket/
  board. Thus an Optional Cpad_1 and Cpad_2 are provided to give default
  pad capacitance values with the assumption that they are not in the mated
  model.

> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > There could be several reasons not to exclude these sections. How can we
> > add additional connections (See comments under Keyword: [Pin Numbers]) or
> > additional components like capacitor filters, ESD clamps and even active
> > devices, to our connector models? We do manufacture connectors that
> > contain such devices. Maybe this makes this .mmf a .ibs for those kinds
> > of devices but since you separated active device models (.ibs) and passive
> > device models (.pkg & .mmf) I need to understand the reasons and consider
> > all of the implications.

  This proposal does not support allowing general networks with a mated model
  file other than composed of the allowable L/R/C networks. Non linear devices
  such as ESD clamps are not included. This could make the proposal and the
  processing of mated models much more complicated for the small percentage
  of connectors with such extensions. Also some simulator vendors have other
  solutions which may handle these complications.

> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > It should be clarified that there is also an [End Define Package Model]
> > keyword.

  Good suggestion for extending the descripton of [Define Package Model].
  The [End Package Model] is defined much further down in the specification.

> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > It should be clarified that there is also an [End Define Mated Model]
> > keyword.

  Good suggestion for extending the descripton of [Define Mated Model].
  The [End Mated Model] is defined much further down in the specification.
   
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

> |*-----------------------------------------------------------------------------
> [Define Mated Model] CONN4X40
> Cpad_1 = .5pF
> Cpad_2 = 1.0pF
> |*

> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > Perhaps some clarification would be helpful here. This is understood to be
> > a manufacturers suggested default value. A value of zero (0) is allowed.
> > This is a parameter that falls outside of the boundaries of the model and
> > is provided as a first level estimate only. Simulators can replace
> > this value as needed.

  Good suggestion for clarification.

> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > I think this Pin Numbering can become very complicated for connectors and
> > cables. e.g., A cable wire can go from pin 2 to pin 3 and possibly to
> > pin 4 also. A connector can have a different footprint on each side with
> > some pins being on one side only and not on the other. e.g., A ground
> > blade could be connected to several pins in a column on one side and a
> > different number of pins in a row on the other side. Or the pins could
> > be in a row on both sides but numbered differently.
> > I am not sure how these complications can be handled. We will need a very
> > generalized interconnection capability within the model. We need to be
> > careful that we do not accept something that will make backward
> > compatibility difficult in the future when more advanced interconnection
> > structures need to be accommodated.

  Because two columns exist, completely different numbering conventions
  may be used on each sides. Also cross connections such as pin 2 on side 1
  to pin 3 on side 2 can be supported. There may be a practical limit to
  the generality provided. The mated model just describes the connector,
  socket or cable ends of that component only. Its numbering convention
  may be different than the footprint that it is attached.

  It becomes a simulator specific problem to provide the connections to
  each side of the mated model. Thus, the proposal supports vendors
  generating mated models with a reasonable numbering convention, but
  not constraining the board to use the same numbering convention. Thus
  each simulator needs some mapping interface. Also, the connection of
  the board to the mated model must distinguish whether it is connecting
  to side 1 or side 2 since the mated model is not presumed to be symmetrical.
  This also provides another argument that the mated model needs to be in a
  separate file and not in a .ibs file.

> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

> | 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 or mated model
> |* 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 +
> | +-----+
> |

> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > I think I understand, and agree with, the current conventions but I am
> > confused by the voltage references. Can you elaborate?

  The context of this description is for the existing IBIS Version 2.1
  package model only. Here I1 and I2 are two different, unrelated pins.
  I agree that this is confusing. The voltages could be with respect to
  a general, undefined ground. However, even within the package model,
  there may be some different reference planes.
  
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

> |******************************************************************************
> |* BIRD28.3 ADDITION
> |******************************************************************************
> |******************************************************************************
> | There are two different ways to extract the coefficients that are reported
> | in the the capacitance and inductance matrices. For the purposes of this
> | specification, the coefficients reported in the capacitance matrices shall
> | be the 'electrostatic induction coefficients' or 'Maxwell's capacitances'.
> | The Maxwell capacitance Kij is defined as the charge induced on conductor "j"
> | when conductor "i" is held at 1 volt and all other conductors are held at
> | zero volts. Note that Kij ( when i /= j) will be a negative number and
> | should be entered as such. Likewise, for the inductance matrix the
> | coefficients for Lij are defined as the voltage induced on conductor "j"
> | when conductor "i"'s current is changed by 1amp/sec and all other
> | conductors have no current change.
> |

> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > 1. Why is "K" used for capacitance instead of "C"? This causes confusion
> > with the inductive coupling coefficient in SPICE which is "K".

1. The K convention existed in one reference paper. However, I agree that
    it is confusing and would prefer a different notation.

> > 2. Why do we care HOW these Matrixes are CREATED if they give valid model
> > performance? After all, these matrixes just represent a set of
> > capacitance and inductance values. As long as the matrix values
> > provided, do not require a simulator to handle them any differently,
> > does it matter? If that is what is really important, how can we say
> > that clearly?

2. In general, the simulator needs to know how the matrices are defined.
    The definitions above are consistent with field solver output formats.
    We may need to clarify your concerns further.

> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

-------- End of Forwarded Message
Received on Thu Apr 4 09:12:03 1996