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

It would be good if people could CC mikelabonte@eda.org in their IBIS
list emails for a while, so I can find out which emails the list is
missing.

Mike

On Mon, Aug 6, 2012 at 11:46 AM, Muranyi, Arpad
<Arpad_Muranyi@mentor.com> wrote:
> 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
> 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]
> Sent: Tuesday, July 31, 2012 1:25 PM
> To: Muranyi, Arpad; 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] On Behalf Of Muranyi,
> Arpad
> Sent: Tuesday, July 31, 2012 1:41 PM
> To: 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? J
>
>
>
>
>
> Thanks,
>
>
>
> Arpad
>
> =================================================================
>
>
>
> From: Brad Brim [mailto:bradb@sigrity.com]
> Sent: Saturday, July 28, 2012 1:19 PM
> To: Muranyi, Arpad; 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, 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