Subject: New package model proposal by Steven Peters

From: [email-masked]
Date: Mon, 8 May 1995 16:59:33 -0700

From: Kellee Crisafulli, HyperLynx Inc.

I feel the last several emails are drifting off the central point.

Steven has presented an egg which appears to provided the data needed,
and do so in a fashion which is a direct extension from the original IBIS work.
We already support both the discrete and matrix approaches the Steven suggested.

Steven has simply suggested extending this to allow multiple levels.

In terms of providing a more advanced simulation.  I believe that the next
IBIS modeling
standard after the simple extension suggested by Steven Peters should
include a physical
representation.

Why create yet another method of describing the package when we have a
method ala
Steven that extends what we alredy have and performs the job very nicely.

Am I missing something here?

Keep it Simple is usually the best approach and it seems to me that Steven
has obseved the KISS principle.

Have a great day...Kellee Crisafulli, HyperLynx Inc.

---

From: [email-masked] (Chrisopher E. Reid)
Date: Tue, 9 May 95 09:21:08 -0400

Hello,

> Am I missing something here?

The problem as I see it is that the Egg proposes one way to model
an MCM which may do for some particular part, but may be inadequate for
some other part. We do not want to add to Ibis a plethora of syntaxes
to support many different package model options.

The matrix package models for pin parasitics are sufficient for traditional
packages. For anything more complicated a different approach is needed.

In general an MCM can be as complicated as a board and requires its
own modeling tool. If such is available then it should be used along
with the models for traces on the board (Cadence SigNoise for example
is currently used in such cases).

Lacking the actual MCM models or the capability of mixing them with
the board models then some other technique is needed. But, that technique
should be as general as possible so that no further extensions in this
direction are required.

One possibility is to use the pin parasitics type package models
(the matrix approach) for the actual pins of a package and use spice
subcircuits with a naming convention to define what pins they attach to.
Such an approach would be perfectly generic, would NOT force unneeded
pins into the circuit, and would never need extension. The Spice elements
used could be restricted to passive elements.

The advantages to this approach are:
  1) Everyone understands the SPICE syntax,
  2) With only passive SPICE elements there are no questions about models,
  3) Extensions would NEVER be needed for any package since every possible
      package could be described in this syntax,
  4) Automatic software would prune the matrix of pin parasitics to
      model only those pins that are needed,
  5) SPICE subcircuits that are not needed are simply ignored by the
      simulator.

Chris Reid

---

From: Stephen Peters <[email-masked]>
Date: Wed, 10 May 1995 09:26:09 -0700

Hello Chris, Kumar, Kellee and others:

>to support many different package model options.

     My proposal was never intended to model MCMs, SIMs, etc. and I belive
we should take a long, hard look before we start trying to describe
what amounts to complex circuit boards.  IBIS is a standard describing
*I/O buffers*; we are concerned about the packaging only is as much as
its effects are inseperable from the actual silicon characteristics.
Also, this proposal is an attempt to refine what has already been defined,
not come up with a whole new scheme.  It does cover existing DIP/SOIC/
PQFP/BGA/PGA/TAB packages -- basicly any package where the leadframe
can be represented as multipule elements in series, with coupling between
any set of arbitary elements.
    This may be a bit of a philosophical discussion, but consider this:
users, given half a chance, would take a '.pkg' file that allows general
descriptions and use it to describe an entire motherboards net topology. 
This may be a 'great and wonderful' thing, but is that the intent of IBIS?

         Regards,
         Stephen Peters