From: Mirmak, Michael Sent: Tuesday, October 16, 2012 1:19 PM To: IBIS-Interconnect (ibis-interconn@freelists.org) Subject: IBIS Interconnect Task Group Oct. 10, 2012 Minutes and Oct. 17, 2012 Agenda ====================================================================== IBIS INTERCONNECT TASK GROUP MEETING http://www.eda.org/ibis/interconnect_wip/ Mailing list: ibis-interconn@freelists.org ====================================================================== Next meeting: Wednesday, Oct. 17, 8 AM US Pacific Daylight Time Agenda: - Attendance - Call for Patents - Agenda and Opens - Weekly Topic - Next Meetings’ Schedule/Agenda Teleconference Logistics For international numbers, please contact Michael Mirmak. 916-356-2663, Bridge: 2, Passcode: 862-5431 Join online meeting https://meet.intel.com/michael.mirmak/QZ193W0C First online meeting? [!OC([1033])!] ====================================================================== Attendees, Oct. 10 Agilent Technologies Radek Biernacki* Cadence Design Systems Brad Brim* Intel Corp. Michael Mirmak* Mentor Graphics Arpad Muranyi* Signal Integrity Software Walter Katz* Teraspeed Consulting Group Bob Ross* Minutes Michael Mirmak called the meeting to order. No patents were declared. Michael reviewed a simple list of keywords from the IBIS 5.1 specification, highlighting keywords that are likely to interact with any new package keyword or package support structure defined by the team. The most significant ones are: [Component] [Package] [Pin] [Package Model] [Pin Mapping] [Diff Pin] [Series Pin Mapping] [Node Declarations] [Circuit Call] [External Circuit] [Define Package Model]/[End Package Model] These assume that keywords such as [Model] and [Model Spec] involve buffers only. Some keywords may be affected due to their relationships to power rails: [Model Spec] for Weak_* [Voltage Range] [Pullup Reference] [Pulldown Reference] [POWER Clamp Reference] [Rgnd] [Rpower] [Rac] [Cac] [Receiver Thresholds] [C Comp Corner] (and, by extension, C_comp in [Model] and [Model Spec]) Additional keywords, such as [Test Load] may be affected due to their use of interconnect. [Series Current] and [Series MOSFET] may also have interactions due to their use of “pin” language. Several attendees suggested that this approach was too specific, and that other issues required immediate attention. Walter Katz mentioned on-die interconnect as being treated differently than packages. The specific technical point is the mapping of pins to die pads. 99.99% of the time there’s a 1-1 mapping between these for signals, but supply die pads violate this assumption. For a 100-power-pin device, when power distribution models are created, some will create shorted models that have just one power path and one die pad to connect to the 100 pins; at another extreme will be 500 die pads to map to 100 pins. Brad Brim concurred with this description. Bob Ross asked, to clarify, if the pin to die pad connection involved the power supply, and whether there might be several of these supply paths to the buffer. Walter replied that he was talking about the power supply distribution network. Arpad Muranyi raised a concern is that this approach should not be hard-coded in the specification, as it would not be healthy to accommodate this with special syntax. Walter suggested that whatever syntax is used needs to accommodate all three options. Bob noted that Pin Mapping supports all three; Walter disagrees, though he notes it was intended to do so. Walter suggested that this intent was to associate a list of supplies to a pin number of a signal. Arpad added that Pin Mapping does cover the intent, but it’s somewhat convoluted. Michael asked whether the number of supply paths to the buffer could be assumed, or whether this was a limitation in IBIS’s structural assumptions. Arpad responded that this is a [Model] problem; we have four supplies for four I-V tables. Michael asked how external reference fits in. Bob and Arpad observed that this was not really a supply. Brad added that lots of buffers have core power and I/O power supplies; core power noise would affect I/O supplies. Arpad asked whether core power is to the logic core or the buffer pre-driver stage? Today’s buffers are really I/Os. Brad replied that supplies are both from the pins; Randy agrees (the assumption is the same for their designs). Walter suggested that Pin Mapping is the most critical item to address for packages along with Define Package Model; the rest are less critical. Bob agreed, stating that decomposition of die pad to pin as one problem, then die pad to buffer pad as another problem. Arpad suggested that a more fundamental question is whether to be model-oriented or not. If this changes, is this forking the specification? Walter replied not, that a precedent is [External Model] and [Model] curves being mutually exclusive. Bob and Arpad responded that this may not apply as an example. Walter noted that [Pin Mapping] does the same things as [Node Declarations] vs. die pads: Node Declarations is just a name, whereas die pads is instantiating things. The function is to associate the signal name with the model name. He added that signal names and die pads would be different; the die pads would be tied to signals implicitly. Arpad and Bob cautioned against implicit links. Walter noted that the links are distinct: - Die pads and signal names are associated in a die pad list - Signal pads and signal names are associated in a pin list Michael suggested that resolving the need for a separate die pads keyword, whether or not Node Declarations was involved, was the key decision for the next meeting. Michael asked Arpad and Walter to provide, for the next meeting, simple drawings showing how their understandings of links between die pads, pins and buffers would be implemented. They were asked to keep the drawings to a page, if possible.