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

From: "Bob Ross" <bob@xxxxxxxxxxxxxxxxx>
To: "'IBIS-Interconnect'" <ibis-interconn@xxxxxxxxxxxxx>
Date: Thu, 10 Oct 2019 12:06:04 -0700

Randy,

One overall rule is that terminal lines should not have overlapping
terminals on any interface.  So, any conflicts (such as bus_label and
signal_name or pin_name) would be reported as an Error.

However, we could explicitly name the rail bus_label column (e.g., VDD and
VDDLL) or specify that when the bus_label entry is missing, it  can default
to the signal_name entry.  That way we can use the Terminal_qualifier
bus_label for both the VDDLL and VDD entries and not have any overlaps.
Also, to address one capability, if a pin or group of pins are known to NOT
be connected, be can assign a different bus_label (e.g., VDD_NC) and never
connect thoses terminal(s).

(We have and the parser enforces a similar "default" rule where a missing
rail [Pin Mapping] terminal is not defined (anywhere) except under [Pin}.

Also, to address the issue that a pin or group of pins are not physically
connected on the EMD, we can assign a different bus_label  (e.g., VDD_NC)
and never connect those terminal(s).  (If a rail pin is not connected in any
attached component or EMD, it could also be omitted from the [Designator Pin
Map] list.)

So, bus_label entries under the control of the EMD modeler provides a
powerful way to group rail pins or omit them

Bob

From: ibis-interconn-bounce@xxxxxxxxxxxxx
[mailto:ibis-interconn-bounce@xxxxxxxxxxxxx] On Behalf Of Randy Wolff
(Redacted sender "rrwolff" for DMARC)
Sent: Wednesday, October 9, 2019 2:24 PM
To: IBIS-Interconnect
Subject: [ibis-interconn] Re: [EXT] The story of Merged Pins

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):

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

=====================================================================

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

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

Other related posts: