MCMs and SIMMs, etc... in IBIS

Hi IBIS gurus,

I am trying to attempt to summarize my reactions to the responses my last
EMAIL generated.

For one thing, Stephen Peters' recommendation does not involve branching
and the like. This in itself prevents it from being a true SIMM and MCM
package description. If our goal is to extend Stephen's EGG to cover
all those devices, we might as well take an advantage of the already
available PCB extraction and field solver tools which do a pretty good
job in this area. As far as I understand, these tools use geometrical
descriptions provided by layout editors. There is no need to reinvent
the wheel by describing the same stuff with a different syntax or
behaviorally in IBIS.

All we need is a simulator which understands multiple boards, have board
descriptions of PCBs, SIMMs and MCMs, and have the IBIS models for the
chips (and dies) that are put on the PCBs, SIMMs and MCMs. This is all
possible today and I heard that it is also being done in some places
already.

It is another story to invent (or find) a common and general PCB, SIMM
and MCM description language which enables all the tools to get data
from a single file format like IBIS does it with buffer models.

To Fred, I would like to respond with saying that it is not enough to
have delay and loading information only for a SIMM or similar device.
You also need topological information to be able to figure out
reflections, cross talk and similar effects.

To Jon I have a question: What makes SIMMs and MCMs an IBIS issue? If
Intel were to put the "P999" die(s) not on a SIMM, (as you suggested),
but an MCM and gave you a PCB-like description of the MCM substrate
(which you could process with your field solver) along with IBIS models
for the die(s), would you need anything else? The IBIS model(s) of the
die(s) could be referenced by the MCM description file which could be
referenced by the motherboard (as if it were an other PCB or component).

To sum it up, I see two opposite IBIS bird migration paths here. (And I
myself am not sure which one is the right one).

1) {To be... } Include geometric or behavioral interconnect
descriptions in IBIS (.pkg-like files) for SIMMs, MCMs, etc... In the
case of geometric descriptions we will have to reinvent the wheel and
provide syntax for all this stuff and convince everyone (layout and
simulation tool vendors) to start using it. If we decide to use
behavioral interconnect descriptions in IBIS, people who make the models
will have to buy their own field solvers, network analyzer and TDR
machines, etc... to be able to put together the matrixes required by
the more ambitious model users.

Both of these would be a vaste, since these functionalities are already
available and running in the board extractors and field solvers of the
simulations tools on the market.

2) {... or not to be?} Exclude all PCB-like descriptions from IBIS and
provide a referencing mechanism to layout tool output files for SIMMs,
MCMs and the like. In this case we could make use of the already
available field solvers and board extraction tools of simulators and
we would only have to convince SIMM and MCM vendors to provide data
about their designs from their layout tools.

{... This is the question}, as I see it.

This PCB-like description of MCMs might be conflicting with my concern I
expressed earlier about revealing possible manufacturing secrets, but I
have a feeling that SIMM and MCM layouts would not be such a big secret
to anyone.

Points 1 and 2 are actually not much different, as I think about it.
The question is, does the geometric board (SIMM & MCM...) description
exists inside or outside IBIS. If it is inside, it becomes a duplicate
of a layout tool output file possibly in a different syntax format. If
it is outside, it might be directly read from the layout tool, which
most simulators can do anyway.

If we are talking behavioral descriptions in IBIS, the model maker will
have to duplicate the work of the field solvers up front.

Any comments?

Arpad Muranyi
Intel Corporation
Received on Fri May 12 09:05:06 1995