============================================================================== IBIS INTERCONNECT TASK GROUP Mailing list: ibis-interconnect@freelists.org ================================================================================ Attendees from February 5, 2025 Meeting (* means attended at least using audio) ANSYS Curtis Clark, Wei-hsing Huang, Juliano Mologni Arista Networks Jim Antonellis Broadcom James Church Intel Corp. Michael Mirmak*, Xiaoning Ye Keysight Technologies Ming Yan Marvell Steve Parker MathWorks Walter Katz* Micron Technology Justin Butterfield Siemens EDA Weston Beal, Arpad Muranyi*, Randy Wolff* Simberian Yuriy Shlepnev ST Microelectronics Aurora Sanna Synopsys Ted Mido, Edna Moreno University of Illinois Jose Schutt-Aine Zuken USA Lance Wang Michael Mirmak convened the meeting. No patents were declared. Michael reviewed the minutes of the December 4, 2024 meeting. Arpad Muranyi moved to approve the minutes; Walter Katz seconded. The minutes were approved without objection. Michael reviewed the minutes of the December 11, 2024 meeting. Some concerns were raised by Arpad, which had also been mentioned on the reflector: 1) “Current flows into a port must also flow out of other ports.” Arpad suggested this was incorrect, suggesting instead that the intent was to say that the current going into one terminal of a port must come out from its other terminal. 2) There is a small typo: “ideal note 0” should be "ideal node 0". 3) The following phrase is missing "per side" after "reference": “The ideal case would be to have at least one reference, one for the die side and one for the board side.” Arpad moved to approve the minutes with these changes. Walter seconded, stating that he objected to the implied claim or statement that the reference per side was a requirement. This was agreed not to currently be a requirement of the Touchstone port-mapping effort. The minutes were approved. Michael summarized the basic objectives of the port-mapping effort, distinguishing between the origin of the Touchstone data and how it will be used in system-wide interconnect descriptions. Walter stated that including how Touchstone is generated is nice to have, but doesn't affect how it is used. This detail is informative, but not normative. Arpad expressed some disagreement, stating that it would be nice to have documentation by the model maker of which ports need to be connected to which node, documented at the time of usage. If a user has a bunch of die pad ports, and others on ball side and the user wants to independently reference them, the user needs to know which ports are referenced to which. Therefore the user needs to know how they were extracted. Michael added that this documentation does not prohibit a change in usage by another user. Are we not constraining the syntax if we put more information into the model outside of differential pair associations? Walter replied that ideal SPICE node 0 is, by definition, how Touchstone files are used in SPICE simulators Weston's example adds a plane that doesn't exist in reality. Arpad stated that what we have in the specification (IBIS Interconnect and EMD) is incorrect today. We cannot necessarily do the right thing; this could also happen in Kinger's SPIM proposal. We need to fix this in IBIS Interconnect and EMD. Walter disagreed, stating that every expert he has talked to says it makes absolutely no sense to connect Touchstone files to anything other than node 0. Arpad replied that this is only true for Touchstone files being connected to other Touchstone files. Connections to IBIS files, for example, may require different referencing schemes. Walter responded that A_gnd is the reference for IBIS. While pulldown_reference, pullup_reference, etc. are used for I-V tables, A_gnd is the reference in turn for these rails. Arpad noted that, if each side is referenced to node zero, there isn't a problem. However, the issue is the N+1 syntax in EMD and IBIS Interconnect. All sides on the pad side could be referenced to pad_ref, while all on ball side could be referenced to ball_ref. Walter and Arpad agreed that they hold fundamentally different views on whether all ports should be referenced to the same node. Michael raised the previous examples of connections between Earth and the moon and Earth and Mars. Arpad suggested limiting the example to a cable with Earth nodes and an Earth reference at one end, and moon nodes and a moon reference at the other. If one is simulating, one can tie both references to node zero as a convenience; as soon as you put something else between Earth and the moon references (e.g., a SPICE subcircuit), you will end up shorting it out if you use ideal SPICE node 0. Walter stated that the specification shouldn't allow doing something that's technically wrong. Randy Wolff added that a recent DesignCon paper shows the problem of connecting two S-parameters, when a larger S-parameter is cut into smaller ones. Walter noted that, so long as the interconnect references on the two sides are close to each other, everything's OK. Arpad stated that he wants a flexible syntax to do this. He does not want the syntax to tell him how to perform the connectivity; that's restrictive. Kinger Cai is saying that specific pins are the reference for SPIM. Randy replied that one needs to group things the same way; it helps to document how the two models are meant to connect. Walter agreed that this information should be documented in the Touchstone data, but *not in the Interconnect Model file*. In IBIS Interconnect, you are documenting how you are using the ports. Port Mapping allows you to define a reference for each port. Michael wondered whether a separate topology specification is needed, aside from the specifications for the individual models (Touchstone, IBIS, etc.). A parser for the topology would catch connection issues. Arpad stated that the team may be trying to use port-mapping for two different things: - automating making EMD models, IBIS Interconnect Models to tell the tool how to connect the models - how the models were measured Walter stated that connectivity is for the EDA tool to decide. Arpad replied, "yes and no". Michael suggested that the reference configuration may already be covered by Port Mapping syntax. Randy added that where the EDA tool is not involved is in IBIS Interconnect Model syntax. One can divide a package into two pieces. Within our own interconnect model syntax, we need to ensure consistency of referencing across connections. Arpad replied that, for the EDA tool to do that right, we need to tell it what is right and wrong. Randy stated that, where something could go wrong, there is some IBIS-specific syntax for EMD port names, and IBIS Interconnect port names are added. We are trying to create the Interconnect model wrapper if it's not correctly defined. Arpad replied that we still need that information. In other words, if we have a list of ports with a common reference, we need to state if there are other ports with another reference. Walter raised the issue of clusters and groups. The new terminology from the recent IBIS-ATM meetings is that a "group" is the name for a collection of nodes on the pin side ("pin cluster" in original syntax), while a cluster is a collection on the pad side. But an IBIS Interconnect model does not allow you to specify anything about the reference, unless it's a common reference. We need to have this in the Touchstone file and not have this in Interconnect. Walter moved to adjourn the meeting. Randy seconded. The meeting adjourned without objection. ================================================================================ Bin List: 1) Complete port naming proposal (Katz et al) 2) Complete/revise Touchstone 3.0 draft outline (Mirmak) 3) Complete ISS-IRD 1 Draft - enable cascading of S-parameters through W-element (Mirmak) - TABLED Tabled ARs: - Arpad to give an example of the physical connectivity needed for EMD automation.