====================================================================== IBIS INTERCONNECT TASK GROUP http://www.ibis.org/interconnect_wip/ Mailing list: ibis-interconnect@freelists.org Archives at http://www.freelists.org/archive/ibis-interconn/ ====================================================================== Attendees from August 3 Meeting (* means attended at least using audio) ANSYS Curtis Clark* Cadence Design Systems Bradley Brim Cisco David Siadat Intel Corp. Michael Mirmak* Keysight Technologies Radek Biernacki, Ming Yan Mentor Graphics Arpad Muranyi* Micron Technology Justin Butterfield*, Randy Wolff* SAE ITC Maureen Lemankiewicz, Logen Johnson Signal Integrity Software Walter Katz*, Mike LaBonte* Teraspeed Labs Bob Ross* University of Aveiro in Portugal Wael Dghais Michael Mirmak convened the meeting. No patents were declared. Review of ARs: AR: No ARs were reviewed. Review of Minutes: The minutes from the July 27 meeting were not yet available. Michael mentioned that he is in the process of finishing them up, and he will be releasing them soon. Opens: Bob raised two issues related to open questions. The first is whether we expect to bring in more than one [Interconnect Model Set] at a time. And the second is how to bring in power and ground and how that relates to the reference. Mike mentioned, in regards to the second issue, that we need to decide whether an interconnect model should have at least one signal or if it can contain PDN connections only. Bob asked, if we have just a PDN set, how are we supposed to use it? Do we expect the tool to use a lower level signal model as a default when a PDN only set is present? And pointed out that this is still an open issue. Michael asked if there was any off-line discussion with Radek and Brad about terminal names for the [Receiver Threshold] format discussion. Bob suggested to defer the discussion until Radek could weigh in, but commented that the C_comp BIRD proposal uses the terminal names similar to the Interconnect BIRD. Walter corrected that the C_comp BIRD uses the [Receiver Threshold] naming. Bob agreed that the terminal names are scoped by the buffer. Walter moved to table the [Receiver Threshold] naming discussion. Bob seconded. There were no objections. Arpad noted that Radek has not been able to attend these meetings regularly. Michael asked to Mike to reach out to Radek to find out his thoughts on the subject. Mike accepted the AR to reach out to Radek about the issue. Interconnect Model Sets Discussion: Michael summarized the main issue is in the organization of the [Interconnect Model Set]s. The issue is whether to encapsulate the sets or to list them out separately. And, how to use the names associated with the sets. Mike confirmed that the sets need to be named in both cases, but that is not the real issue. Bob reiterated that the issue is whether [Interconnect Model Set]s are done by reference versus explicit definition. Mike noted that are two issues. The first is whether the [Interconnect Model Set]s should call the [Interconnect Model]s by reference or have them embedded. The second issue is if you might bring in more than one model set at a time, and how the package models will be implemented by the simulator in those cases. Walter mentioned his presentation material went into both of these issues and requested to share and go over the material. Walter shared a document (IMS.PDF) showing the questions and the relation to his proposal. In regards to first question of "Are [Interconnect Model]s scoped by the [Interconnect Model Set], or do they appear in the top level in an IBIS file and just referenced by the [Interconnect Model Set]?", he points out that almost every component has either a pin 1 or A1. Thus, it is logical to identify the [Interconnect Model]s by the pins. And defining the [Interconnect Model]s in this manner will create collisions between multiple [Interconnect Model Set]s. Arpad asked about the case where a parameter such as length in passed into the same models. Walter replied that his examples will clarify how that is handled, but that it is a difference between subckt and the instances of those subckts. He presented examples of collisions with two of the same packages from two different vendors with two different [Interconnect Model Set]s. In package A, it has package connections to A1, A2, etc. and a power delivery network. A1 is an identifier, and all of the 4 signals use the same subckt with a different length. The PDN calls a different subckt. The only difference for package B is a different file name for the ISS file. Walter reasoned the most logical way to name the [Interconnect Model]s is by the pins. Bob pointed out there are disadvantages in terms of telling the models apart. Walter moved to his second question, which states "Must all [Interconnect Model]s in a single [Component] used in a single simulation be in a single [Interconnect Model Set], or can they be in multiple [Interconnect Model Set]s within a single [Interconnect Model Set Selector]?". He pointed out that it might be convenient for separate interconnect model sets. He gave an example of having separate [Interconnect Model Set]s for DDR4, PCIe, SATA, and the PDN and how this could result in many different combinations. He wondered, can we accomplish simulation combinations without adding more data into the model. An include style could allow these combinations or by calling by reference. Randy asked if we can have multiple sets, one with uncoupled and one with coupled signals. What would happen if this results in multiple paths? Walter thought we should avoid this case with multiple sets that have the same IO pins. Mike suggested that we focus on the first question in Walter's presentation and come back to the second question later. Bob agreed as well. Bob commented that if we have multiple copies of the same package then it makes sense to include them by reference. He added that there is no requirement that the [Interconnect Model] name is the pin number, but it does make sense. But you could also append the name with the package name. Walter added that you would have to append the package name in order to ensure you have a unique name. Bob agreed that it is possible to have multiple packages/components in an IBIS file. He showed a Micron model example (z80a.ibs) that has two different packages with same pin out. The two packages share the [Package Model] and could be a good case for reuse when the sets are defined by reference. He showed a second ECL model (mc10elt2x.ibs and mc10elt2x.ims) example with eight pin components that use the same package. In this example, each package could have a separate [Interconnect Model], but the [Interconnect Model] names would have to be appended with the package name (package1, package2, etc.). He argued that this approach gives better clarity over Walter's proposal, and it is an advantage that unique names are used. He also pointed out that this approach is similar to the [Add Submodel] syntax. And that there are efficiencies if you can reuse [Interconnect Model]s resulting in fewer lines in the IBIS files. Bob moved to defer the vote on which proposal to adopt. Mike seconded. There were no objections. Mike moved to adjourn. Bob seconded. The meeting adjourned without objection.