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

  _____

From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Muranyi,
Arpad
Sent: Friday, July 27, 2012 5:01 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

Sam,

Thanks for the answer I finally see the reason and usefulness

for it.

But I have question. What is the reference for the coordinates?

Is there a universal rule for where 0,0 is? What if the PCB

uses a different reference point from the package (or the package

from the die)? Are tools expected to try all possible translations

to see if they can be overlaid and find a position that makes

contact?

Thanks,

Arpad

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

From: Sam Chitwood [mailto:samchitwood@sigrity.com]
Sent: Friday, July 27, 2012 1:01 PM
To: Muranyi, Arpad
Cc: 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,

With regard to including coordinates, it's extremely useful for GUI based
tools to automatically make the connections when the die / package / PCB
naming conventions are different. Otherwise the user has to manually figure
out the mapping.

Thanks,
Sam

On Wed, Jul 25, 2012 at 12:54 PM, Muranyi, Arpad <Arpad_Muranyi@mentor.com>
wrote:

Walter, and Everyone,

Thanks for the overview on the physics of package models. I still

wonder, however, why we need to concern ourselves with this, as far

as the specification goes.

This is what I came away from the ATM meeting yesterday:

1) provide a syntax that allows the use of IBIS-ISS subcircuits

2) provide a syntax that provides mechanisms to place them

between the [Model] terminals and any die node (bump, pad, etc.)

for on-die interconnect modeling, or between any die node (bump,

pad, etc.) and the pin or ball of the component for package

modeling

3) the connectivity syntax has to have the ability to describe

full or partial (slice) package or on-die interconnect models

4) the connectivity syntax has to support fixed topologies and

generic topologies, i.e. the legacy IBIS or the Intel approach

(we can also call this "swathing" or "sliding model" approach)

5) the connectivity syntax must be able to support arbitrary package

or on-die interconnect topologies (i.e. forks, splits, joins,

reduction or expansion of power connections, etc.)

It seems to me that if we can fulfill these requirements in the spec,

we would not have to worry about the physics part, or the content of

the IBIS-ISS subcircuit. It could contain anything the model maker

desires, T-coils, signal or power nets, coupled or uncoupled traces,

model the C_comp in one place or multiple places, etc..

I would also like to comment on the x-y coordinate idea from MCP. I

can see why that would be useful for a field solver, but I am not sure

why we should support that in the IBIS specification. At the IBIS level

we deal with electrical models. Connections are made with nodes and

terminals. I don't see how x-y coordinates would help or be useful on

this level.

Please feel free to correct me if I am wrong. I am still learning.

Comments and suggestions are welcome.

Thanks,

Arpad

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

From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Walter
Katz
Sent: Tuesday, July 24, 2012 3:02 PM
To: ibis@eda.org
Subject: [IBIS] IBIS-ISS Package Modeling : The Physics of a Package Model,
Presentation to IBIS-ATM 7/24/12

All,

Presentation to IBIS-ATM 7/24/12

E-Mail comments:

1. "Well said"

2. What about MCM (Multi-Chip-Modules)?

a. Will be addressed when EBD is enhanced to include IBIS-ISS package
models

3. What about package discretes (e.g. Blocking Caps, Pullup and
Pulldown Resistors)?

a. IBIS-ISS is a subset of HSPICE including S-Parameter, W-Lines and
discretes

Rather than discussing the possible IBIS solutions for package models, I
would like to describe the physics of the problem, and then ask some
questions of what part of the physics need to be implemented.

I would like to frame these questions with an example:

Package

150 VDD Pins

150 VSS Pins

100 Single Ended Channel Pins

Die Bump Pads

200 VDD Bump Pads

200 VSS Bump Pads

100 Single Ended Channel Bump Pads

Die Buffer Pads

100 VDD Buffer Pads

100 VSS Buffer Pads

100 Single Ended Channel Buffer Pads

Complete Package Model (describes the full physics of the package
interconnect)

150 VDD Pins

150 VSS Pins

100 Single Ended Channel Pins

200 VDD Bump Pads

200 VSS Bump Pads

100 Single Ended Channel Bump Pads

900 total ports

Complete On-Die Model (describes the full physics of the die interconnect)

200 VDD Bump Pads

200 VSS Bump Pads

100 Single Ended Channel Bump Pads

100 VDD Buffer Pads

100 VSS Buffer Pads

100 Single Ended Channel Buffer Pads

A Full Simulation will consist of

Board and all of the stuff on the Board

1 Package model instance

1 on-die model instance

100 IBIS buffers

Connections that need to be rectified

400 connections between Board and Package Model

500 connections between Package Model and On-Die Model

300 connections between On-Die Model and 100 Buffer Models

Questions to IC Vendors:

Is this setup is a completer representation of the problem?

Yes, No one disagrees.

Is it practical to produce the Package Model and On-Die Model in this level
of detail?

No, anyone disagree? (Scott Disagrees, Arpad Disagrees)

Package Model is a s900p

On-Die Model is a s800p

Do you want/need to use a subset of the On-Die VDD and VSS Bump Pads in your
On-Die Model?

Do you want to be able to represent the VDD and VSS Bump Pads as two nodes?

Chip size ~.5"

Tpd ~180ps/inch

Max freq if just two nodes ~10GHz

"User" can only control Board power routing, Board bypass caps and VCM,
<~1GHz at package pin

Do you want/need to use a subset of the Package VDD and VSS Pins in your
Package Model?

Do you already include the interconnect between the Channel Bump Pads and
Channel Buffer Pads in your Buffer Model?

For legacy IBIS, On-Die routing is accounted for in C_Comp

For AMI modeling, On-Die routing and buffer impedance is included in On-Die
S-Parameter models

RC Ladder Circuit

Do you need interconnect between VDD and VSS Bump Pads and VDD and VSS
Buffer Pads, or is it sufficient to "tie" each VDD and VSS Buffer Pad to
specific VDD and VSS Bump Pads.

Does "User" need power frequency > 10GHz

Do you want to be able to distribute Package and On-Die Models for slices
(subsets) of the 100 Channels?

Package Model Slices

Uncouple Channel Package Subckt for each Channel Pin

Coupled Channel Package Subckt for each Channel Pin

Uncouple Channel Package Subckt for each Channel Pin in a Bus

Couple Channel Package Subckt for each Channel Pin in a Bus

Coupled Channel Package Subckt for specific Channel Pins

Package Power Models for a subset of Package Pins

Coupled Channel and Power Package Subckt for specific Channel and Power Pins

On-Die Model Slices

Simple C-Die between VDD and VSS

On-Die Channel Models

.

IBIS-ISS Package Subckts Now Being Distributed by IC-Vendors

IC Vendor A

10 Channel Package Models

3 process corners

Package Models are assigned to specific Pins

IC Vendor B

1 Channel Package Model

3 process corners

Each Pin has a unique Length which is passed to the subckt as a parameter

IC Vendor C

1 Package Model

1 Victim Channel, 2 Aggressor Models

FEXT (Far End Crosstalk)

5 Process Corners

IC Vendor D

1 Package Model

1 Victim Channel, 2 Aggressor Models

FEXT (Far End Crosstalk)

9 Process Corners

IC Vendor E

1 Package Model

1 Victim Channel, 3 Aggressor Models

Mixture of FEXT and NEXT (FEXT for Data, NEXT for Clock). NEXT = Near End
Crosstalk

9 Process Corners

IC Vendor F

Package Model of Custom Slice of Package CAD Data Base

On-Die Model of Custom Slice of IC CAD Data Base

Models stitched together using MCP protocol written into the SPICE subckt by
EDA Layout Extraction Tools

MCP (Model Connection Protocol) enable stitching of models together by
defining "Connections"

Package Model has a Connection to the Board and a Connection to the Die

Each Connection associates its Nodes in the .subckt statement with

Pin Name

Net Name

X,Y coordinate

EDA tools associates Nodes in the Connections by one or a combination) of
the following

Pin Name Heuristic (e.g. 1C == C01)

Net Name (DQS# == DQS-)

X, Y coordinate (deals with rotation, mirror, shift, units)

IBIS-ISS On-Die Subckts Now Being Distributed by IC-Vendors

C-Die between Power and Ground

S4P for AMI Buffers

Do you want to be able to distribute multiple Package and On-Die Models with
different combinations of the choices above?

Walter

--------------------------------------------------------------------
|For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org
|with the appropriate command message(s) in the body:
|
| help
| subscribe ibis <optional e-mail address, if different>
| subscribe ibis-users <optional e-mail address, if different>
| unsubscribe ibis <optional e-mail address, if different>
| unsubscribe ibis-users <optional e-mail address, if different>
|
|or e-mail a request to ibis-request@eda-stds.org.
|
|IBIS reflector archives exist under:
|
| http://www.eda-stds.org/pub/ibis/email_archive/ Recent
| http://www.eda-stds.org/pub/ibis/users_archive/ Recent
| http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993
Received on Sat Jul 28 11:19:18 2012