[ibis-interconn] Re: [EXT] The story of Merged Pins

From: "Randy Wolff" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "rrwolff" for DMARC)
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx>
Date: Wed, 9 Oct 2019 21:24:22 +0000

Arpad,

I am replying to your thread instead of starting my own, since I provide some
examples below that are useful to discussing [Merged Pins], and this whole
example is about syntax for merging rail pins.

(Walter, we had a good discussion today in Interconnect about the syntax for
Terminal definition of Rails.  I had an incomplete example to review of [EMD
Model] syntax for a full-package SPICE model of the same stacked-die DRAM
package discussed last week.)

Here is some relevant info from the EMD model for use in looking at options for
defining the Pin_Rail terminals, example shown for one Rail, VDD.  VDD also has
one ball (J1) which is routed separately from the rest of the VDD balls,
providing noise immunity for the DLL.  The signal name of J1 is labeled as VDD
in the datasheet, although using this signal_name complicates merging
(shorting) of the other VDD pins into single terminals (discussed below in
Terminal examples).  In the SPICE model there are separate terminals for the
VDDDLL BGA ball and U0/U1 die pads.  I highlighted in yellow the VDDDLL pins,
relevant to further discussion.

[EMD Pin List]  signal_name     signal_type  bus_label
B3              VDD             POWER
B9              VDD             POWER
D1              VDD             POWER
G7              VDD             POWER
J1              VDD             POWER        VDDDLL
J9              VDD             POWER
L1              VDD             POWER
L9              VDD             POWER
R1              VDD             POWER
T9              VDD             POWER
[End EMD Pin List]

[EMD Designator Map]
| Designator  File reference    Component name
U0            z11b.ibs          MT40A1G8Z11B
U1            z11b.ibs          MT40A1G8Z11B
[End EMD Designator Map]

[Designator Pin List] signal_name     signal_type     bus_label
U0.1                 VDD             POWER           VDD_U0
U0.17                 VDD             POWER           VDD_U0
U0.33                 VDD             POWER           VDD_U0
U0.49                 VDD             POWER           VDD_U0
U0.65                 VDD             POWER           VDD_U0
U0.67                 VDD             POWER           VDD_U0
U0.68                 VDD            POWER           VDDDLL
U0.73                 VDD             POWER           VDD_U0
U0.95                 VDD             POWER           VDD_U0
U0.110                VDD             POWER           VDD_U0
U0.116                VDD             POWER           VDD_U0
U1.1                 VDD             POWER           VDD_U1
U1.17                 VDD             POWER           VDD_U1
U1.33                 VDD             POWER           VDD_U1
U1.49                 VDD             POWER           VDD_U1
U1.65                 VDD             POWER           VDD_U1
U1.67                 VDD             POWER           VDD_U1
U1.68                 VDD            POWER           VDDDLL
U1.73                 VDD             POWER           VDD_U1
U1.95                 VDD             POWER           VDD_U1
U1.110                VDD             POWER           VDD_U1
U1.116                VDD             POWER           VDD_U1
[End Designator Pin List]

The ISS subcircuit has the following terminals for VDD and VDDDLL for which to
define Terminal lines in [EMD Model]:
85: VDD at U0 (merged)
86: VDD at U1 (merged)
87: VDDDLL at U0, pin 68
88: VDDDLL at U1, pin 68
155: VDD at BGA balls (merged)
156: VDDDLL at BGA, pin J1

Here are some terminal line options we talked about, some requiring new syntax
to support use of signal_name or bus_label along with Designator:

|Terminal terminal_type terminal_type_qualifier qualifier_entry

| First option using pin_name for designators(only option fully defined in the
BIRD)
85   Pin_Rail  pin_name
U0.1,U0.17,U0.33,U0.49,U0.65,U0.67,U0.73,U0.95,U0.110,U0.116
86   Pin_Rail  pin_name
U1.1,U1.17,U1.33,U1.49,U1.65,U1.67,U1.73,U1.95,U1.110,U1.116
87   Pin_Rail  pin_name     U0.68
88   Pin_Rail  pin_name     U1.68
155  Pin_Rail  signal_name  VDD
156  Pin_Rail  pin_name     J1

VDDDLL complicates the syntax above, since it has the same signal_name as VDD.
Does use of signal_name VDD conflict with the pin_name J1?

Another option for defining the VDDDLL terminal with bus_label, even though the
bus has only one pin:

156  Pin_Rail  bus_label    VDDDLL

Again, is there a conflict due to the signal_name?

Back to exploring options for Terminal syntax at Designators:

| Second option using signal_name for designators(requires new syntax)
85   Pin_Rail  signal_name     U0.VDD
86   Pin_Rail  signal_name     U1.VDD

This could cause issues with VDDDLL bus_label...

| Third option using bus_label for designators(requires new syntax)
85   Pin_Rail  bus_label     U0.VDD_U0
86   Pin_Rail  bus_label     U1.VDD_U1

This seems to avoid issues with VDD signal_name and VDDDLL.

To tie into Arpad's email about [Merged Pins], here is where we run into
potential problems:

155   Pin_Rail  pin_name  B3

If an EDA tool has a fine-grid PDN SPICE model for a PCB that includes
terminals for VDD at each BGA ball, and it wants to mate it to a EMD model that
lists a single pin (as above), or only a few VDD pins at the  BGA interface,
what does it do?

It's obvious that if you use signal_name VDD, then you have one terminal to
connect to all the PCB terminals (shorting them together).

This also makes me wonder if we should have syntax allowing multiple pin_names
for the Terminal line:

155   Pin_Rail  pin_name  B3,B9,D1

So, if you broke the model into subsections of VDD at the BGA interface, you
could indicate the shorted pins.  Or, could this be handled through bus_label
only?

Seems we need to state a rule about what to do when not all pins are merged, or
an incomplete list of pins is included in the model.

Thanks,
Randy

From: ibis-interconn-bounce@xxxxxxxxxxxxx <ibis-interconn-bounce@xxxxxxxxxxxxx>
On Behalf Of Muranyi, Arpad
Sent: Wednesday, October 09, 2019 12:33 PM
To: IBIS-Interconnect <ibis-interconn@xxxxxxxxxxxxx>
Subject: [EXT] [ibis-interconn] The story of Merged Pins

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:image001.png@01D57EB4.9CB665B0]

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: Bob Ross

References:
- [ibis-interconn] The story of Merged Pins
  - From: Muranyi, Arpad

[ibis-interconn] Re: [EXT] The story of Merged Pins

Other related posts: