[ibis-interconn] The story of Merged Pins

From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx>
Date: Wed, 9 Oct 2019 18:32:48 +0000

Hello Everyone,

We had a discussion in the Interconnect Modeling Meeting today about PDN models
and their connectivity syntax in EMD, and I made a comment that we should make
sure that the new EMD syntax can describe everything that the legacy [Merged
Pins]
syntax was invented to describe.  I want to prevent the possibility that
someone may
want to use the legacy syntax because it can do something that the new EMD
syntax
cannot do...  So I would like to summarize the reasons [Merged Pins] was
invented so
we won't forget about its purpose and features.

I am not saying that the EMD BIRD is missing any of this (because I don't know
at this
moment), I just want to make sure that we don't miss out on this.  These
thoughts
were triggered in my mind this morning when Randy was showing his PDN model
example...

Before [Merged Pins] was added to the IBIS spec, we started to see package
models
described by [Define Package Model] as follows:

The [Pin Numbers] keyword listed only one (or a few) of the numerous
power/ground
pins that were listed in the [Pin] keyword of the component.  The [Model Data]
associated with this (these) pin(s) included a parallel combination of the
package effects
for all the remaining pins that were not listed in the [Pin Numbers] keyword,
but were
present in the [Pin] list.  The problem was that the IBIS specification did NOT
define what
the EDA tool was expected to do for the pins which were present in the [Pin]
keyword
but were missing in the [Pin Numbers] keyword.

There were two possibilities.  One interpretation was to short those missing
pins to
their corresponding die pads.  The justification for this interpretation was
that since
power has to get to the die pad somehow, a missing package model should imply a
short between the pin and the pad.  The other interpretation was to place an
open
between the pin and the corresponding die pad.  The justification for this
interpretation
was that if a package model is not defined, nothing should be put in its place.

The problem with these two interpretations was that if the model maker assumes
an
open, but the EDA tool places a short between the pins and die pads for the
missing
pins under the [Pin Numbers] keyword, the merged model becomes ineffective due
to the shorts the EDA tool places between the undefined pins and their
corresponding
die pads and the shorts between the die pads defined by the busses in the [Pin
Mapping]
keyword.  Since both interpretations are equally valid, and there was a need to
support
merged pin package models, we had to clarify the IBIS specification, which is
how the
BIRD with [Merged Pins] was born.

The [Merged Pins] keyword allows the model maker to explicitly define which
power
or ground pins in the [Pin Numbers] keyword contain merged pin information, and
lists
the pins which are merged into that pin.  The usage rules also state that those
merged
pins must be shorted with the merging pin (pg. 164):

[cid:image002.png@01D57EA6.094845E0]

Using this information the EDA tool knows which pins are merged with which
other pins,
and that instead of shorting those pins to their corresponding die pads, they
should be
shorted to their merging pin.  I would like to make sure that we can describe
the same
information in the new EMD syntax as well.

Questions/comments/corrections are welcome...

Thanks,

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

Follow-Ups:
- [ibis-interconn] Re: [EXT] The story of Merged Pins
  - From: Randy Wolff

[ibis-interconn] The story of Merged Pins

Other related posts: