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

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

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