Re[2]: Future directions for IBIS ... IBIS 2000

In the "for what it's worth" category:

For a little while now, some of us have been deeply involved with the creation
of a connector model specification.

Included in the PROPOSED specification (THIS IS NOT A FINAL SPECIFICATION YET):
* SLM: Single Line Model definition (non-coupled)
* MLM: Multi Line Model definition (COUPLED)
* CMLM: Cascaded Multi Line Model definition (COUPLED)
* Matrix based modeling
* by R, L, C matrices (Inductance matrix is a "partial inductance matrix")
* Fixed Pin mapping (to help facilitate nodal style interconnects)
* Floating pin mapping (pin mapping set up to be flexible to accept different
size models. (Does this mean that there is a provision to create a variable
size model.. based on the matrix construct?.... Yes, it does!)
* "Swath" matrix operator... basically allows the inclusion of a variable size
model (especially for connectors). Kind of like an automated banded matrix.
* Ability to cascade matrices. As such one connector (interconnect?) model can
be made up of multiple cascaded and stub matrices. As such, keeping some (most)
frequency dependence. Obviously, this really depends on the "completeness" the
model creator. (There is also a "minimum risetime definition" in the model to
help assist users of the model)
* coupling
* expanded line length
* included a reference to jpg file for the model
* model ftp / www site address for updates

Some of the items could be added into the general spec if deemed worthy.

What we did not put in to the specification at this time:

* Behavioral modeling of interconnects. The most popular way to do this for an
interconnect is probably s-parameters. This is seen as a potential FUTURE
upgrade to the specification. As it was thought that the most important thing
to do was to get some interconnect models into the IBIS stream.

* The specification was set up to deal with most (99%??) of today's connector
issues. As such it can deal with many other interconnect issues as well
(package, cable, other?).... but, it is not perfect for them. For example...
cables.... for cables, it would probably be nice to have Propagation Delay and
Impedance (maybe admittance too?) matrices directly. Yet, another future
upgrade....??

Other issues:
* With SPICE, it was generally known how Berkeley SPICE will handle: L, C, R,
and k values. Unfortunately, we do not have the luxury with non-SPICE
simulators that use IBIS.
* With the creation of connector SPICE models... The model creator controlled
the "circuit" generated from the matrix. In this case, each simulator will be
able to generate one or more kinds of circuit for each R,L,C matrix set. This
can be good and bad.
* It will still be possible for someone to connect a "perfect ground" to both
sides (input and output ports) of a connector. This will effectively ruin the
simulations based on that circuit construction that use COUPLED models. The
more that I follow the list.. the more I think that the standard IBIS "I/V"
curves are generated by the use of a "perfect ground". Hopefully, simulators do
not need to assign a "perfect ground" in the every equation that references a
IBIS semiconductor model.

BOTTOM LINE:
Every connector that can be represented by a SPICE model today.. can also be
represented by the matrix approach in the Connector Specification.

I am not sure on the access that you may have to the "0.92 PROPOSED IBIS
Connector Specification. If required, I can supply a URL to the site.

_gus: 630-969-4617
apanella@molex.com

____________________Reply Separator____________________
Subject: Re: Future directions for IBIS ... IBIS 2000
Author: "Paul Franzon" <paulf@eos.ncsu.edu>
Date: 11/22/99 6:22 PM
<SNIP>
Sorry, Ted, I was not clear. I meant an RLC matrix in Spice format.
This handles losses and coupling. It can also handle frequency-dependent
losses in a practical sense (ie. up to a cutoff frequency).

The advantages are that the format is well known, widely used and
can handle just about anything (though sometimes a little clumsilly
e.g. S-parameter information has to be fitted to an RLC ladder network).
The disadvantages is needing a smart parser for other formats, e.g.
S parameters.

It sounds like you are leading towards the concept of the 'Universal
parser' for packaging-related info and with some common format. ie. Take
in format X, produce simulatable format Y for simulator Z. A lot of
these pieces already exist, scattered around various vendors. Also,
Verilog-AMS
and VHDL-AMS most likely has standards for some of these formats. A
Universal parser would be a significant development effort. Many parts
of this would have definite value as some of the vendor stuff is very
buried in one simulator or expensive.

Regards,

Paul
<SNIP>
Received on Tue Nov 23 04:21:30 1999