[ibis-macro] Re: Straw Poll vote on IBIS-ISS Package Modeling

  • From: "Walter Katz" <wkatz@xxxxxxxxxx>
  • To: <Arpad_Muranyi@xxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Wed, 15 Aug 2012 08:14:05 -0400 (EDT)

Arpad,

 

The following statements are totally incorrect:

 

Using EBD as a package to house multiple components (each of

which describes a packaged die) looks a little strange to me,

even if the component's package model is zeroed out.

 

For this reason I think that using EBD for multi-chip package

modeling is NOT the right thing to do.  It simply doesn't fit

the IBIS hierarchy.

 

This is exactly what EBD was designed for, and are being used for, and are
being delivered for.

 

Walter

 

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, August 15, 2012 1:44 AM
To: IBIS-ATM
Subject: [ibis-macro] Re: Straw Poll vote on IBIS-ISS Package Modeling

 

Hello everyone,

 

I feel that it would be a little too early to take a vote with

these questions, because it seems that there are a few things

we need to clear up first.  Here is one issue:

 

Randy commented today that he would like to have multi-chip

capabilities within a package.  This is not listed in the

questions.  I do remember Walter's answer to that comment

being that we can do it with EBD, but I am not so sure about

that.  It seems that we have a hierarchical problem there.

 

Looking at "Section 3a" in the v5.0 specification on pg. 13

I see [Package] and [Package Model] under [Component].  This

indicates that [Component] doesn't refer to a die, but it

refers to a packaged die.  In order to have multiple, possibly

different dice in the same package, we would need to have 

another keyword which is lower than [Package] or [Package Model]

in the hierarchy for the die.  Currently we don't have this.

The IBIS specification seems to be architected with the one

die per package assumption.

 

Looking at the architecture of the EBD specification, I see

the [Reference Designator Map] keyword which is responsible

to associate any reference designators (U1, U2, etc.) listed

in any "Node" entries of the .ebd file with an .ibs file and

component name.  The syntax in EBD is RefDes.PinName where 

PinName is the pin name of a component.  This clearly assumes

that a component that is referenced by the reference designator

of EBD is a packaged die (since it is using a pin name, not a

pad name).

 

Using EBD as a package to house multiple components (each of

which describes a packaged die) looks a little strange to me,

even if the component's package model is zeroed out.

 

For this reason I think that using EBD for multi-chip package

modeling is NOT the right thing to do.  It simply doesn't fit

the IBIS hierarchy.

 

Comments, questions welcome.

 

Thanks,

 

Arpad

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

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Tuesday, August 14, 2012 4:19 PM
To: IBIS-ATM
Subject: [ibis-macro] Straw Poll vote on IBIS-ISS Package Modeling

 

All,

 

I have put 28 questions in a spreadsheet. I think it will take too much
time to do the voting in the meeting, so I request that you put entries
1:4 in column 1 of each question. The meanings of 1:4 are.

 


4

Advocate   I need this!


3

Support      I support this


2

Abstain       I have no opinion


1

Object         I object to this functionality

 

Return them to me or all IBIS-ATM and I will collate the results and
publish them by Tuesday AM. I am including the .xlsx file in case you have
difficulty editing the spreadsheet in the body of this e-mail. Also
including this and last weeks presentation.

 

Walter

 


4

Advocate   I need this!


3

Support      I support this


2

Abstain       I have no opinion


1

Object         I object to this functionality


 

 


 

Should we add keywords Pullup_Signal_name, Pulldown_Signal_name,
Power_clamp_Signal_name, and Ground_clamp_Signal_name to the [Model]
section?


 

Should we add a section to the .ibs file to define the voltage values of
supply signal names?


 

Should we add a list of supply die pad names?


 

Should we add an x-y coordinate for each pin and die pad?


 

 


 

Should we support two signal pins connected to the same die pad (Forked
Signal)?


 

Should we be able to associate a package model with a [Model]?


 

Should we be able to associate a package model with a Pin_name?


 

Should we be able to associate a coupled package model with a [Model]?


 

Should we be able to associate a coupled package model with a list of
Pin_names?


 

Should we support package models with coupling between signals and power?


 

Should we support a coupled package model that hooks up to two or more
[Model] names?


 

Should we support package models with more than 3 corners?


 

Should we support package Touchstone files directly?


 

Should we support sparse usage of large package Touchstone files?


 

Should we support package "Quadrants" (e.g. Banks, Interfaces)?


 

Should we support full package models?


 

 


 

Should we support on-die models?


 

Should we be able to associate an on-die model with a [Model]?


 

Should we be able to associate an on-die model with a Pin_name?


 

Should we be able to associate a coupled on-die model with a [Model]?


 

Should we be able to associate a coupled on-die model with a list of
Pin_names?


 

Should we support on-die models with coupling between signals and power?


 

Should we support a coupled on-die model that hooks up to two or more
[Model] names?


 

Should we support on-die models with more than 3 corners?


 

Should we support on-die Touchstone files directly?


 

Should we support sparse usage of large on-die Touchstone files?


 

Should we support on-die "Quadrants" (e.g. Banks, Interfaces)?


 

Should we support full on-die models?

 

 

Walter Katz

wkatz@xxxxxxxxxx

Phone 303.449-2308

Mobile 303.335-6156

Other related posts:

  1. Home
  2. ibis-macro
  3. Archive
  4. 08-2012