Subject: MCMs and SIMMs, etc... in IBIS

From: Arpad Muranyi <[email-masked]>
Date: Fri, 12 May 95 08:45:00 PDT

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