[ibis-macro] Re: Straw Poll vote on IBIS-ISS Package Modeling error in slide 11
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <Arpad_Muranyi@xxxxxxxxxx>, "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 15 Aug 2012 08:18:09 -0400 (EDT)
Arpad,
Slide 11 is missing the [Model_ports] section. The syntax is the same for
all of my examples, the only difference is that port either has a
(Pin_name A1) or a (Model_name DQ), and if differential and Model_name
also requires a (Polarity +) or (Polarity -). Presentation with the update
to slide 11 is included.
Walter
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, August 15, 2012 2:19 AM
To: IBIS-ATM
Subject: [ibis-macro] Re: Straw Poll vote on IBIS-ISS Package Modeling
Walter,
Here is another reason I feel that these questions need to be
reviewed before we are ready for a vote:
Looking at slides 10 and 12, I think we could develop a common
syntax that can be used for either example. Based on that, I
still don't understand why we need to answer multiple questions
(such as lines 15, 17, 19, 20, 24, 25 in the Excel Spreadsheet)
which could be all addressed with one and the same syntax.
The same comment applies to lines involving the on-die interconnects.
And if we stretch our imagination a little further, I could even
see the same syntax being used whether it is "by model name" or
"by pin name" but I am not sure about this because it seems that
the example on slide 11 is missing something. It looks like that
it is making an instance of a one port package model (subcircuit)
connection to pin A1. Looks like that the "Model_ports" branch
or something similar is missing from the tree.
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:
