[ibis-macro] Re: X-Y coordinates for IBIS package modeling?
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "ibis@xxxxxxx" <ibis@xxxxxxx>, 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 7 Aug 2012 19:18:58 +0000
"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@xxxxxxx<mailto:ibis@xxxxxxx>
ibis-macro@xxxxxxxxxxxxx<mailto:ibis-macro@xxxxxxxxxxxxx>
markh@xxxxxxxxxxxx<mailto:markh@xxxxxxxxxxxx>
mikelabonte@xxxxxxx<mailto:mikelabonte@xxxxxxx>
Thanks,
Arpad
============================================================
From: owner-ibis@xxxxxxx [mailto:owner-ibis@xxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, August 06, 2012 10:47 AM
To: ibis@xxxxxxx
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@xxxxxxx<mailto:ibis@xxxxxxx>
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@xxxxxxxxxx]<mailto:[mailto:wkatz@xxxxxxxxxx]>
Sent: Tuesday, July 31, 2012 1:25 PM
To: Muranyi, Arpad; ibis@xxxxxxx<mailto:ibis@xxxxxxx>
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@xxxxxxx<mailto:owner-ibis@xxxxxxx>
[mailto:owner-ibis@xxxxxxx]<mailto:[mailto:owner-ibis@xxxxxxx]> On Behalf Of
Muranyi, Arpad
Sent: Tuesday, July 31, 2012 1:41 PM
To: ibis@xxxxxxx<mailto:ibis@xxxxxxx>
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@xxxxxxxxxxx]<mailto:[mailto:bradb@xxxxxxxxxxx]>
Sent: Saturday, July 28, 2012 1:19 PM
To: Muranyi, Arpad; ibis@xxxxxxx<mailto:ibis@xxxxxxx>
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.
Other related posts:
- » [ibis-macro] Re: X-Y coordinates for IBIS package modeling? - Muranyi, Arpad
