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