[IBIS] RE: X-Y coordinates for IBIS package modeling?

"Take 2"...

If you want to reply or post your own message(s), please
use ALL four of these email addresses so we can track down
the issues on the IBIS email reflector:

ibis@eda.org<mailto:ibis@eda.org>
ibis-macro@freelists.org<mailto:ibis-macro@freelists.org>
markh@infoarch.com<mailto:markh@infoarch.com>
mikelabonte@eda.org<mailto:mikelabonte@eda.org>

Thanks,

Arpad
============================================================

From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Muranyi, Arpad
Sent: Monday, August 06, 2012 10:47 AM
To: ibis@eda.org
Subject: [IBIS] X-Y coordinates for IBIS package modeling?

Hello Everyone,

It seems that the server's intermittent behavior last week
turned people off from continuing this conversation. I am
going try to resurrect this thread with a new subject line
because I think this is an important topic.

I would like to put Brad and/or Sam on the spot and ask if
you could take a few minutes to respond to the questions I
raised in my last message in this thread.

Thanks in advance. I hope the email server is not going to
get in our way this time...

Arpad
=============================================================

From: Muranyi, Arpad
Sent: Tuesday, July 31, 2012 1:53 PM
To: ibis@eda.org<mailto:ibis@eda.org>
Subject: RE: [IBIS] IBIS-ISS Package Modeling : The Physics of a Package Model, Presentation to IBIS-ATM 7/24/12

Walter,

It seems that it is being proposed to include x-y coordinates
and/or MCP in the IBIS specification. I am asking these
questions because I don't want to put something into the
specification that is either useless, or prevents the majority
of the simulators from working with the models, etc...

I think these questions are important and large enough to have
to address them before we put these features into the spec.

Thanks,

Arpad
===============================================================

From: Walter Katz [mailto:wkatz@sisoft.com]<mailto:[mailto:wkatz@sisoft.com]>
Sent: Tuesday, July 31, 2012 1:25 PM
To: Muranyi, Arpad; ibis@eda.org<mailto:ibis@eda.org>
Subject: RE: [IBIS] IBIS-ISS Package Modeling : The Physics of a Package Model, Presentation to IBIS-ATM 7/24/12

Arpad,

The issues you bring up are MCP issues, not IBIS issues. It is of course trivial to build examples that will defeat xy coordinate matching. But I also think it would be very hard to build a real case that would defeat coordinate matching. If MCP every becomes an IBIS standard, then that would be the time to deal with these issues.

That should not prevent us from adding xy coordinates for pins and die pads into IBIS to enable MCP or equivalent.

Walter

From: owner-ibis@eda.org<mailto:owner-ibis@eda.org> [mailto:owner-ibis@eda.org]<mailto:[mailto:owner-ibis@eda.org]> On Behalf Of Muranyi, Arpad
Sent: Tuesday, July 31, 2012 1:41 PM
To: ibis@eda.org<mailto:ibis@eda.org>
Subject: RE: [IBIS] IBIS-ISS Package Modeling : The Physics of a Package Model, Presentation to IBIS-ATM 7/24/12

Brad, Sam,

Thanks for the explanations.

Question about "an EDA chip database typically has its origin in the lower left corner":
When we talk about corners, are we talking about the corner
of the die (package) or the coordinates of the bump/ball/pin
nearest to that corner? I don't know what the usual practice
is, but I can see it both ways. If it is done both ways, this
can introduce an additional level of complications.

Regarding the EDA tool "...must consider coordinate translations, rotations and axial flips",
I wonder if that is a reasonable expectation from circuit
simulators which do not have the features of displaying
physical images of the device. I am thinking of any SPICE
simulator and similar tools here. It seems that all of
these tools would be excluded if we went this route.

Regarding "The algorithm can apply information such as: pad names, net
names, pad type (pwr/gnd/signal), intra- and inter-database relationships amongst
multiple pads, etc", it seems that we are getting into a circular
reasoning here. In an earlier message the reason for needing
x-y coordinates was that in case pad/bump/ball/pin names are
not matching we could make connections based on x-y coordinates.
Now you say that the unavoidable translation/rotation/flipping
might need pad names in order to work... So what comes first,
the chicken or the egg? :)

Thanks,

Arpad
=================================================================

From: Brad Brim [mailto:bradb@sigrity.com]<mailto:[mailto:bradb@sigrity.com]>
Sent: Saturday, July 28, 2012 1:19 PM
To: Muranyi, Arpad; ibis@eda.org<mailto:ibis@eda.org>
Subject: RE: [IBIS] IBIS-ISS Package Modeling : The Physics of a Package Model, Presentation to IBIS-ATM 7/24/12

hi Arpad,

No global coordinate system exists.
An EDA tool that creates a model publishes (X,Y) values in its local coordinate system. There is no way it can know anything else.
An EDA tool that applies the model to perform electrical analysis doesn't really care about the coordinates for any one model, but when it much connect one (or more) models it must consider coordinate translations, rotations and axial flips.
This is not as ambiguous or difficult as it might first seem. Let's examine a flipchip and single-die package.
Per industry practice, an EDA package database typically has its origin in the center of the package and its X-axis is usually flipped with respect to the chip database. Also per industry practice, an EDA chip database typically has its origin in the lower left corner. It is relatively easy for a human to interactively look at an image of the two pad sets and guide an EDA tool to connect them properly with flips/rotations/translations. However, it is not all that difficult for one to code a reliable algorithm to perform this task automatically. The algorithm can apply information such as: pad names, net names, pad type (pwr/gnd/signal), intra- and inter-database relationships amongst multiple pads, etc. Not all information is available in all cases; and even if it is, there may be ambiguities such as pad name mismatches. For real designs the available information is more than adequate to reliably align pad sets at model connection boundaries. Most designs are intentionally constructed to avoid manufacturing misalignment, which also enables the task of automated model alignment. Yes, one could imagine a case for which alignment ambiguity might still exist. For example, a set of pads with total symmetry of locations, types, net names, no pad name matches, etc. In this case additional information could be specified, such as a "preferred coordinate transformation", a set of reference pads, etc.

best regards,
 -Brad

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--------------------------------------------------------------------
|For help or to subscribe/unsubscribe, e-mail mikelabonte@eda-stds.org
|or ibis-request@eda-stds.org
|
|IBIS reflector archives exist under:
|
|  http://www.eda-stds.org/ibis/email_archive/ Recent
|  http://www.eda-stds.org/ibis/users_archive/ Recent
|  http://www.eda-stds.org/ibis/email/         E-mail since 1993