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

From: Sam Chitwood <samchitwood@sigrity.com>
Date: Fri Jul 27 2012 - 11:00:52 PDT

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 Fri Jul 27 11:01:18 2012

This archive was generated by hypermail 2.1.8 : Fri Jul 27 2012 - 11:01:57 PDT