RE: [IBIS] IBIS-ISS Package Modeling : The Physics of a Package Model, Presentation to IBIS-ATM 7/24/12

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 Wed Jul 25 10:54:42 2012