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

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
  • Date: Wed, 15 Aug 2012 06:37:34 +0000

After my previous two messages, we only have the first
four questions left on which I would like to comment on
in this email.


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

We already have reserved names for these.  Pg. 101 of
the v5.0 spec lists them all, but here are the relevant
ones:

| 4 A_puref Voltage reference port for pullup structure
| 5 A_pcref Voltage reference port for power clamp structure
| 6 A_pdref Voltage reference port for pulldown structure
| 7 A_gcref Voltage reference port for ground clamp structure
| 8 A_signal I/O signal port for a model unit

True, these are listed for [External Model], but we all know that
the terminals of [Model] and [External Model] are identical.  I
would prefer to find ways to use these names instead of inventing
new names.  There might be several ways to achieve that, one of
which is the way BIRD 145 proposes it.


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

We need to understand this question a little better before we can
answer it.  We already have supply voltage related keywords in the
specification.  We need to understand whether those might work or
not for the purpose you want to use them for, and then ask this
question.


Should we add a list of supply die pad names?

Why do we need to distinguish between signal and supply die pad
names?  A die pad is a connection point, whether it is signal or
power.  Once we have a mechanism to declare them we can make
connections to them.  The existing [Node Declarations] keyword
could be used to make such declarations for die pads.  I would
like to understand this question better before I would vote on
it.


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

I think we should answer some of those questions I asked in email
on this and the IBIS reflectors earlier, which I repeated in the
meeting today.  I think we need to be very careful about writing
a specification which by its nature might exclude a lot of
simulators from working if models were written with x-y coordinates.
We should also answer the questions on who is the user of the IBIS
models, and whether they can or cannot get their work done without
the x-y coordinates.  Are those "early adopters" you were referring
to in the meeting today able to get their jobs done with more
specialized tools which can use those databases which are based on
x-y coordinates, or do they do their work with IBIS models?  Are
these types of users the majority, or the minority?  Etc...

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<mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 303.335-6156

Other related posts: